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ABSTRACT 


This  project  develops  a  framework  to  permit  the  introduc- 
tion of  combat  effectiveness  as  a  high  level  objective:  func- 
tion to  the  naval  ship  design  process.  This  is  effei  ced  by 
the  development  of  a  model  of  the  sources  of  mission 
requirements  for  the  design.  Interaction  and 
inter-connection  of  the  design  stages  is  provided  by  design- 
ing the  model  around  the  menu-oriented  software  system  known 
as  DEX  (Decision  Executive  System). 

The  model  used  the  commonality  of  its'  design  and  the  DEX 
commands  and  prompts  as  the  means  of  insuring  that  all  par- 
ticipants to  the  design  process  have  access  to  the  assump- 
tions used  to  develop  combat  effectiveness  as  an  objective 
function.  The  possible  capabilities  of  the  model  are  exhib- 
ited through  simple  examples  which  show  the  extreme 
situation  dependency  of  combat  effectiveness  assesiiments. 
The  possible  implications  of  the  use  of  the  model  for  future 
research  in  Naval  Architecture/  Marine  Engineering  r^re  dis- 
cussed. 
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CHAPTER  1 
INTRODUCTION  TO  THE  PROBLEM 

The  objective  of  this  work  was  to  establish  a  set  of 
independent  variables  to  describe  a  mono-hull  surface 
combatant  ship  (naval  vessel)  and  to  determine  its  mission 
effectiveness.  This  determination  will  be  made  at  the  fea- 
sibility stage  of  the  design  and  will  be  dependent  upon  the 
environment  in  which  the  design  is  to  operate.  It  was 
determined  that'  all  variables  would  be  specified  by  their 
contribution  to  specific  missions.  It  was  expected  that  the 
determination  of  these  contributions  would  eventually  permit 
an  evaluation  of  the  designs'  combat  effectiveness.  As  in 
any  large  scale  system  definition,  the  question  of  appropri- 
ate level  of  detail  was  critical.  This  project  will  attempt 
to  specify  these  independent  variables,  both  in  number  and 
in  detail,  sufficiently  to  permit  determination  of: 


1.  feasibility   under   known   or   assumed  technological  and 
budgetary  constraints 

2.  combat  effectiveness 

3.  non-combat  mission  effectiveness 

4.  cost  effectiveness. 


Progress  in  the  development  of  this  set  of  independent 
variables  was,  initially,  very  uneven.  The  first  problem 
was  to  establish  a  complete  listing  of  all  missions  for  such 
a  ship.  It  was  determinted  that  the  best  existing  list  of 
this  sort  would  be  a  good  point  of  departure  for  this  prob- 
lem. Research  toward  finding  such  a  document  eventually 
lead  to  a  publication  entitled  Naval  Warfare  Mission  Areas 
and  Required  Operational  Capability,  also  known  as  OPNAV 
Inst.  3501. 2E.  This  instruction  is  used  to  indicate  which 
mission  areas,  of  all  possible  U.  S.  Navy  missions,  have- 
been  assigned  to  a  particular  class  of  vessels.  It  also 
lists  the  assigned  missions  by  the  portion  of  the  ships' 
organization  (operations,  engineering, etc . )  which  the 
mission  is  assumed  to  affect.  As  such,  this  instruction  is 
an  excellent  attempt  to  describe  all  missions  which  a  par- 
ticular ship  is  "expected"  to  be  able  to  perform  when 
properly  (fully)  manned  and  when  all  installed  equipment  is 
fully  operational. 

The  possible  missions  listed  in  OPNAV  Inst.  3501. 2E  could 
be  broadly  separated  into  two  categories;  combatant  and 
non-combatant.  Within  this  instruction,  the  descriptions  of 
the  two  types  of  missions  are  quite  different.  A  typical 
noncombat  mission  entry  might  be  described  as  "Search  and 
Rescue",   with  the  the  equipment  and  training  levels  for  the 
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ship  and  crew  being  specified.  Conversely,  A  typical  combat 
mission  entry  might  be  "Force  and  Area  Air  Defense",  and 
would  generally  be  without  any  further  explanation. 

This  "underspecif ication"  of  many  missions  within  this 
publication  is  most  clearly  shown  in  the  listing  of  many 
general  combat  missions.  In  our  previous  examples  of  Force 
and  Area  Air  Defense,  the  problem  with  the  statement  of  the 
mission  is  that  it  is,  in  addition  to  being  somewhat  subjec- 
tive, very  "relative".  It  is  most  relative  to  the  forces 
which  might  be  attempting  to  defeat  the  proposed  defense. 
It  is  also  dependent,  among  other  things,  upon  which  other 
ships  are  in  company.  In  short,  the  whole  mission  area  can 
only  be  defined  in  terms  of  a  broad  spectrum  of  possible 
situations. 

Since  the  non-combat  mission  area  assignments  in  OPNAV 
Inst.  3501. 2E  were  considered  satisfactorily  specified,  this 
publication  was  chosen  as  the  basis  for  the  selection  of 
hardware  resources  necessary  to  perform  those  types  of 
missions.  The  combat  mission  areas,  however,  were  not 
defined  well  enough  within  that  instruction  to  be  used  to 
determine  the  direct  effect  of  the  missions  upon  the  ship 
and  its'  systems.  Therefore,  it  was  necessary  to  establish 
a  methodology  within  the  model  which  would  permit  sufficent 
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description  of  combat  type  missions.  This  framework  was 
intended  to  provide  that  definition  by  allowing  the  mission 
to  be  described  in  terms  of  the  operational  environment 
within  which  the  ship  would  be  designed.  This  environment 
will  include  the  contributions  or  detriments  to  combat 
effectiveness  created  by  man-made  and  natural  situations 
which  the  design  might  encounter  in  combat.  Later,  it  was 
found  that  this  "threat  and  environment"  model  would  form 
the  foundation  for  the  evaluation  of  combat  effectiveness  of 
a  ship.  It  must  be  kept  in  mind  that  both  the  platform  and 
the  payload  were  being,  thusfar,  described  only  in  terms  of 
what  they  must  do.  We  were  carefully  avoiding  any  attempt 
to  define  the  missions  in  terms  of  the  means  to  be  used  to 
accomplish  them. 

Now,  we  may  address  the  various  independent  variables 
defining  our  theoritical  ship  in  terms  of  the  requirement 
but  more  importantly  in  terms  of  the  source  of  the  require- 
ment. The  other  two  major  sources  of  naval  ship  mission 
requirements  were  assumed  to  be;  1.  Non-combat  mission 
requirements  -  it  was  assumed  that  the  requirements  of  OPNAV 
Inst  3501. IE  satisfactorily  listed  these.  2.  Estimated 
time/cost  requirements;  which  might  be  considered  a  form  of 
filter  to  the  first  level  feasibility  of  the  conceived  pay- 
load.    If   all   possible  sources  of  the  defining  parameters 
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can  be  identified  then  we  may  be  assured  of  addressing 
requirements  in  the  construction  of  our  model.  To  this 
point  we  have  identified  the  types  of  vessel  requirements  as 
follows; 


REQUI REMENT 


SOURCE 


— Combat  Payload 

+ 

--Non-Combat  Payload 
Equals  "PAYLOAD" 


— Opponent,  Environment,  Fore 

in  company 
— U.  S.  Navy  (through  society 


In  the  same  vein; 


REQUIREMENT 


SOURCE 


•Payload 

+ 
•Platform  Parameters 
Equals  "SHIP" 


— as  above 

for  payload 
--Naval  Architect  as 
per  guidance  provided 
by  others 


The  assumption  made  to  this  point  is  that,  if  the 
requirements  of  the  different  "sources"  of  ship  character- 
istics  could  be  clearly  and  completely  defined,  we  could 

8 


translate  these  requirements  into  hardware;  that  is  a  ship. 
Even  if  we  were  entirely  successful  in  this  difficult  trans- 
lation, we  would  be  left  with  two  important  questions.  1, 
How  "good"  was  the  ship  we  had  created?  2.  What 
technique(s)  could  we  use  to  permit  timely  processing  and 
data  manipulation  of  the  numerous  items  which  must  be 
included  in  even  the  simplest  of  ships? 

The  answer  to  the  question  of  assessment  of  the  "quality" 
of  the  designed  ship  depends  in  large  measure,  upon  the 
assessors'  definition  of  "goodness".  In  other  words,  it 
might  well  change  with  a  change  in  assessor.  With  this  in 
mind,  the  next  logical  step  in  the  development  of  our  model 
would  be  a  tabulation  of  all  significant  measures  of  surface 
combatant  vessel  "performance". 

Previous  ship  synthesis  models  (we  will  roughly  define 
SSMs  as  computer  aided  interconnection  of  the  various  ship 
design  sub-stages)  have  focused  upon  the  "non-combat"  type 
performance  measures.  Toward  the  assessment  of  such  items 
as  cargo  carrying  capacity,  rates  and  costs  and  even  total 
"life  cycle"  costs,  these  models  have  made  significant 
progress.  In  our  case,  we  have,  with  the  development  of 
the   combat   situation   framework,   provided,  in  theory,  the 


information   necessary   to  conduct   a  measurement  of  combat 
performance  within  the  design  process. 


Model  Outline 

We  can  now  look  at  the  "flow  chart"  describing  our 
approach  to  designing  a  Mono-hull  surface  combatant  and  the 
assessment  of  that  design.  See  figure  1. 

As  will  be  recalled,  the  general  approach  was  to  ,  first 
account  for  the  different  independent  variables  "driving" 
the  design,  by  source.   Referring  to  figure  1  these  were; 


The   environment   in  which  it  would  perform  the  "combat" 
missions  (la) 

The  "non-combat"  missions  to  be  performed  (lb) 

The   material   and   financial  resource  considerations  of 
both  missions  (Ic) 


10 


(start  3~~K^ 


200 


lA 

THREAT 


(300 


IB 
CN  O 


TRANSLATION 

(INCLUDING 
FUNCTION) 


IC 

COST/ 
MATERITO^S 


ZZ7- 


COMPUTATION/TRANSLATION 


INPUT 


0 

o 


OUTPUT 


DECISION    POINT 


■LINK 


<Ve' 


8 

VESSEL 
WITH    EFi:Ei3TIVENESS 


DIRECT 
PAYLOAD" 
INPUT 


COMBAT 
SIMULATION 


POSSIBLE 
DECISION 
POINT 


300' 

T 


MAJOR 
DECISION 


PAYLOAD 


MAJOR 
DECISION 


/Xdecisi 
\/~STOP 


translation 


6 

vessel 

,WITH  PERFOPi-lANCE 


The  simple  identification  of  these  requirements  is  a  nec- 
essary but  not  sufficient  step  in  the  total  design  of  a  ves- 
sel. We  must,  then  identify  the  "blend"  or  "mixture"  of  the 
hardware  items  created  by  those  requirements  into  a  measure 
of  "goodness"  or  more  correctly  a  "measure  of 
effectiveness".  More  precisely,  we  will  look  at  the  problem 
as  a  determination  of  the  resultant  effectiveness  of  a  spe- 
cific combination  of  the  variables. This  determination  was 
made  using  utility  theory  (see  chapter  5) 

The  major  synthesis  steps,  as  provided  for  in  this  model 
would  be; 

Translation  of  mission  requirements  into  a  payload  (Tl) 

Translation  of  platform  parameters  into  a  "ship"  (T2) 

Estimation   of   the  ship  in  terms  of  non-combat  perform- 
ance (El) 

Estimation   of   the   ship  in  terms  of  combat  performance 
(E2) 

Model  Design  Philosophy 

Before  describing  the  model  in  detail,  we  will  discuss 
the  "design  philosophy"  of  the  model.  The  following  charac- 
teristics were  determined  to  be  the  most  important  in  the 
development  of  the  model. 

1.  "Performance"  Based 

2.  Computer  based  with  the  DEX  software  (see  chapter  2) 
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3.   Highest  level  development 

Performance  Based 
Most  existing  ships  synthesis  models  might  be  best  described 
as  the  "one  shot"  method,  where  the  objective  becomes  the 
satisfaction  of  a  set  of  given  requirements.  These  are  usu- 
ally the  ability  to  carry  a  certain  amount  of  equipment,  or 
perhaps,  some  type  of  vessel  charactertics  such  as  geometry 
and  powering.  The  problem  with  this  type  of  approach  is 
that  the  input  is  considered  invioliate  and  the  user  can  not 
regard  any  violation  of  assumptions  made  at  an  earlier  stage 
of  the  design  which  lead  to  these  conclusions.  An  associ- 
ated problem  with  this  approach  is  that  to  reach  such  a 
state  of  specification  the  user  most  likely  conducted  much 
preliminary  work  prior  to  exercising  the  model.  In  short, 
much  of  the  most  involved  design  work  has  been  conducted 
external  to  the  possible  assistance  of  the  computational  and 
data  storage/retrevial  abilities  of  the  computer.  A  third 
problem  common  to  most  existing  models  is  the  virtual  lack 
of  interaction.  The  essentially  batch  or  "one-shot"  method 
used  in  most  adequately-supported  models  requires  the  entire 
process  to  be  repeated  to  discover  the  effect  of  any 
changes. 

As  bothersome  as  the  perviously  described  shortcomings  to 

existing   SSMs  might  be,  the  lack  of  adequate  effectiveness 
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measurement  is  far  more  serious.  Most  common  measurements 
are  implicit  co-relationships  of  displacement,  fuel  or  man- 
ning levels  to  cost.  Such  variables  are, indeed,  important 
to  the  peace  time  portion  of  the  life  of  the  vessel.  They 
do  not,  however,  address  the  true  reason  for  existance  of 
the  combatant,  that  is  its  performance  in  combat,  itself. 
Historically  such  an  assessment  has  ,  at  best,  been  con- 
ducted totally  separate  from  any  non-combat  performance 
evaluation.  In  the  most  common  practice,  any  combat  system 
design  performance  evaluation  is  conducted  on  a  single  sys- 
tem by  system  basis  without  any  integration  of  the  system 
resource  requirements  upon  the  vessel  design.  For  example, 
the  performance  evaluation  and  resource  requirement  iden- 
tification for  an  anti-air  missle  system  would  not  address 
any  impact  of  those  resources  upon  the  performance  of,  say 
the  anti-submarine  weapons  suite.  In  truth,  the  earliest 
time  a  total  design  is  subjected  to  a  combat  performance 
analysis  is  usually  after  initial  fleet  introduction  of  the 
design.  At  this  point  the  ship  is  "synthsized"  according  to 
its  "major"  characteristics  and  modeled  by  interested  activ- 
ities. These  models  are  then  "gamed"  against  similarly 
conceptualizsed  opponets.  Two  important  points  should  be 
noted.  First,  this  process  is  done  after  we  have  paid  full 
price  for  the  vessel  without  the  opportunity  to  correct  any 
discovered  weaknesses   prior   to  completion.    Second,  the 
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information  of  how  the  "modelers"  "fought"  the  ship  is  not 
retained. 

It  will  be  the  implicit  assumption  of  this  effort  that 
the  proper  assessment  of  a  combatant  ship  design  should 
include  an  internal  estimation  of  "combat  effectiveness". 

DEX  as  the  computer  software  package 

Given  the  necessity  for  computer  aid  in  the  modeling  of 
the  complex  ship  design  process,  the  choice  of  operating 
software  becomes  critical.  The  major  characteristics  of  the 
DEX  (Design  Executive)  system,  chosen  for  this  model,  are 
included  in  chapter  2.  Also  included  in  that  chapter  are 
the  effects  of  those  DEX  characteristics  upon  the  capabili- 
ties of  the  model. 

'  Highest  Level  Development 

In  the  development  of  any  model,  the  selection  of  the  char- 
acteristics which  will  be  used  to  describe  the  modeled  enti- 
ty is  critical.  The  challenge  is  to  include  all  necessary 
characteristics  and  no  unnecessary  ones.  In  the  development 
of  this  model,  an  attempt  has  been  made  to  identify  all 
those   variables  needed  to  formulate  the  problem  at  the  fea- 
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sibility  level.  It  is  intended  that  the  model  provide  for 
the  inclusion  of  all  variables  which  could,  at  this  feasi- 
bility level,  affect  the  evaluation  of  the  designs'  combat 
effectiveness. 
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CHAPTER  TWO 
The  Design  Executive  System  (DEX) 

The  methodology  for  this  model  was  designed  to  be 
installed  within  the  Design  Executive  System  (DEX)  under 
development  at  Massachusetts  Institute  of  Technology  and  the 
University  of  Mighigan.  DEX  is  a  self-contained  software 
package  which  is  adaptable  to  almost  any  computer  system 
supporting  fortran.  It  provides  a  system  for  running  task 
based  programs,  called  "modules".  Primarily,  DEX  supports 
interactive  programs  and  it  rrovides  this  interaction  by 
communication  between  five  "parties".   These  parties  are; 

1.  The  user 

2.  The  computer 

3.  '  The  computation  program 

4.  The  source  of  the  input 

5.  The  destination  of  the  output 

The  degree  of  active  involvement  with  DEX  is  within  the  pre- 
rogative of  the  person  writinj  the  particular  application 
program.  That  is  the  "module  author"  may  choose  which  DEX 
services  to  use 

There  are  five  major  characteristics  of  DEX: 
1.   The  user  is  in  the  design  loop. 
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2.  DEX   allows   the   design   process  to  be  executed  in  more 
than  one  sequence, 

3.  DEX  "talks"  to  the  user  in  plain  english. 

4.  DEX  is  "forgiving". 

5.  DEX  has  multiple  capabilities  for  input  and  output. 
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1.  The  user  is  in  the  design  loop.  The  ship  design  spiral 
vividly  demonstrates  the  strongly  iterative  nature  of  the 
ship  design  process.  The  ability  to  perform  data  manipu- 
lations to  a  specific  point  and,  then,  analyze  those  results 
to  decide  where  or  if  to  proceed  is  vastly  preferrable  to  a 
"through-puf'operation.  DEX  enables  the  user  to  choose  a 
new  path,  obtain  new  information  or  to  edit  and  insert 
information  before  it  is  used  within  computation  sections. 

2.  DEX  allows  the  design  process  to  be  executed  in  more  than 
one  sequence.  This  is  accomplished  by  providing  the  user 
with  a  scheme  for  generatiag  menus  within  his  application 
program.  The  use  of  "menus"  to  provide  the  user  with  a 
range  of  choices  of  possible  decision  paths  toward  his  goal. 
A  menu  is  a  list  of  options  (with  a  current  maximum  of  12 
per  menu)  from  which  the  user  chooses  to  either  define  a 
data  value  or  proceed  to  the  next  step  of  the  operation. 

An  example  of  a  menu  is  included  in  figure  2.  If  the 
user  desired  to  specify  or  identify  a  type  of  weapon  from 
this  menu,  he  would  type  in  sufficient  characters  to  unique- 
ly identify  that  weapon  within  that  menu.  Examples  might  be 
"t"  for  torpedo  or  "aa.m"  for  AA.msl.  The  subprogram  would 
accept  this  choice,  if  valid,  and  execute  the  segment  of  the 
program  that   is  logically  associated  with  the  menu  choice. 
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to    calling 
sub  program 


WEP.TYPE 

■< n 

GUN 

GUN 

^    s 

TYPE 

J 

TORPEDO 

RANGE 

AA.MSL 

RATE 

ASU.MSL 

RELOADS 

ASW.MSL 

DONE 

^ 

DONE 

FIGURE    2 


If  the  entry  is  not  valid,  the  user  will  be  prompted,  again, 

for   an  entry  from  the  same  menu.   It  is  not  necessary  that 

the  menu,   itself,   be  displayed.   If  the  user  is  familiar 

with  the   choices   within  the  menu,  he  might  be  prompted  to 

make  a  choice,  from  memory,  by  seeing  displayed 

*enter  an  item  from  menu-wep. type 

If   however,  the  user  does  not  know  the  choices  of  this  menu 
he  could  type 

$  display  menu-wep. type 
to  have  the  menu  displayed  by  DEX. 

Note  the  use  of  "done"  as  the  last  menu  item  in  figure  2. 
A  sub  program  with  a  menu  containing  "done"  returns  to  the 
sub  program  which  called  it  only  when  "done"  is  selected. 
Without  "done"  the  control  of  the  program  is  automatically 
returned.  Such  a  menu,  therefore,  can  only  have  one  choice 
made  at  a  time.  The  user  is  free  to  choose  menu  item(s)  as 
desired.  This  means  there  is  no  predetermined  path  through 
a  group  of  related  of  "stringed"  menus,  the  user  specifies 
the  path. 
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3.  DEX  talks  to  the  user  in  plain  english.  The  menus,  mes- 
sages and  questions  to  the  user  generated  by  DEX  have  been 
specifically  designed  to  be  as  easily  understood  as 
possible.  The  instructions  which  the  user  must  supply  are 
intended  to  be  as  nearly  "conversational"  in  nature  as  they 
could.  All  dialoge  encountered  by  the  user  has  also  been 
standardized  within  the  DEX  modules  as  much  as  possible  to 
reduce  learning  effort  when  using  a  new  program. 

4.  DEX  is  forgiving.  Because  of  the  extended  "pathing"  of 
DEX,  there  is  considerably  more  "mental  discipline"  required 
in  its'  use.  Because  of  this  additional  "thinking"  the  pos- 
sibility of  error  is  also  increased.  These  errors  might 
range  from  inadvertently  depressed  keys,  to  errors  in 
desired  process.  When  existing  sections  of  DEX  and  its 
library  routines  were  developed,  as  many  potential  errors 
and  corresponding  diagnostic  messages  as  possible  were 
anticipated  and  included.  When  an  error  is  detected  control 
is  always  returned  to  the  user  for  resolution  of  the  error 
without  interrrupting  the  execution  of  DEX  or  the  module. 

5.  Multiple  input-output  capability.  DEX  is  designed  to 
permit  communication  between; 
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1.  Data  Bases 

2.  Disk  Files 

3.  Terminal  screen  for  alphanumeric  characters  or  graphics 

In  general,  the  DEX  operating  environment  may  be 
described  as  having  a  total  of  five  "sources"  of  information 
and  four  information  "destinations".  The  term  "information" 
is  used  in  preference  to  input  or  output  to  reflect  the 
duality  and  inter-changability  of  these  two  processes.  For 
this  reason,  the  author  will  apply  the  term  "information"  to 
variables  which  might  be  input  or  output,  as  values  having 
source  or  destination. 

The  sources  and  destinations  for  information  provided 
within  the  DEX  operating  environment  are: 

1.  DEX-created  data  bases 

2.  The   user   via   terminals   using  DEX  routines  to  read  or 
write  alphanumerics 

3.  The   user   via   terminals   or  plotters  using  graphics  to 
read  or  create  x-y  co-ordinate  plots 

4.  Sequential  files 

5.  Module  default  (source  only) 


21 


The  user  may  use  a  different  type  of  destination,  as  his 
source  may  use  different  sources  for  information.  For  exam- 
ple, the  user  might  read  information  from  multiple  data 
bases  and  write  the  information  to  another  terminal  or  a 
file  or  both.  The  only  restriction  is  an  essential 
out-growth  of  logic;  a  module  can  be  directed  toward  only 
one  source  or  destination  at  a  time. 

As  may  be  obvious,  DEX  offers  considerable  improvement  in 
facilitation  of  interactive  design  process  management.  It 
is  designed  to  be  consistent  and  flexible,  providing  "room" 
for  the  required  magnitude  and  differing  forms  of  informa- 
tion, processes  and  paths  required  in  modern  ship  design. 

An  explanation  of  DEX  sufficient  to  develop  the  reader 
into  a  proficient  DEX  user  will  not  be  included  in  this 
paper.  An  excellent  reference  toward  that  end,  however,  is 
An  Investigation  into  the  Use  of  Data  Bases  in 
Computer-Aided  Design,  by  LT  Richard  Celotto,  USN  1981.  It 
will  be  necessary  to  describe  the  major  terms  used  in  the 
system  to  permit  easy  reference. 

DEX  consists  of  three  levels  of  programs: 

1.  DEX  proper-  These  several  hundred  subroutines  provide 
the  operating  "umbrella"  of  DEX.  These  subroutines  are 
designed  to  provide  a  uniform  appearance  of  the  system 
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to  the  user  of  the  various  modules.  In  general,  they 
provide  consistent  input-output  and  data  manupulation 
capabilities  throughout  the  system. 

Extented  DEX  library-  this  is  a  collection  of  45  subrou- 
tines and  general  functions  designed  to  facilitate  the 
construction  of  a  module  with  a  program  specific 
purpose.  These  include;  reading,  writing,  editing,  unit 
conversion,  and  messages  and  status  indications. 

Module-  A  module  is  a  complete  set  of  subprograms  writ- 
ten and  executed  together  to  perform  a  specific  task. 
It  may  only  have  one  program  or  it  may  have  many  addi- 
tional subprograms  employing  menus  to  take  full  advan- 
tage of  DEX  and  any  extended  library  functions  desired. 


One  concept  of  DEX  is  critical.  DEX  identifies  a  vari- 
able within  a  data  base  by  its  name  and  not  by  its  location. 
To  use  this  capability,  the  data  base  must  be  properly  con- 
structed by  the  use  of  the  command  in  the  DEX  proper  main 
menu  "DBEDCMDS"  or  the  data  base  management  routines  listed 
in  Celoto  pg  30.  Once  these  format  rules  have  been 
observed,  arrangement  of  variables  within  the  data  base  may 
be  made  without  regard  to  sequence.  Thus,  for  example,  if  a 
user  needed  the  value  in  a  data  base  corresponding  to  a 
ships  length,  he  might  retrieve  that  value  at  address 
"length".  He  would  not  have  to  specify  (or  know)  that  the 
desired  value  is  in  the  fourth  or  tenth  entry  in  the  data 
base.  This  is  a  powerful  and  new  approach  and  it  permits  a 
user  unfamiliar  with  a  specific  data  base  to  obtain  included 
information  with  much  less  prompting  instruction. 
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Another  very  important  feature,  a  feature  absolutely 
critical  to  an  interactive  process,  is  that  it  can  be  edited 
from  within  DEX  but  outside  a  user  module.  This  capability 
allows  the  user  to  over-ride,  if  he  desires,  a  program  cre- 
ated result  and  input,  directly,  an  alternative. 
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CHAPTER  3 
Section  Development  Example 

This  chapter  will  outline  the  techniques  used  to  develop 
the  sections  outlined  in  chapter  1.  The  section  chosen  for 
this  explanation  is  "Threat  and  Environment". 

The  initial  work  within  each  section  was  to  research  the 
general  topic;  in  this  case  the  natural  operating  environ- 
ment and  the  possible  combat  threats  which  our  design  might 
encounter  in  the  performance  of  its  assigned  missions.  In 
the  beginning  of  the  effort  it  was  important  to  be  alert  to 
any  and  all  information  on  the  subject.  Thus,  the  earliest 
work  was  directed  to  put  the  widest  possible  bounds  about 
the  area.  In  this  early  stage,  the  best  source  of  these 
bounds  was  conversations  with  leading  academic  and  profes- 
sional experts  in  the  field.  Other  early  sources  included 
professional  journals,  proceedings  of  applicable  societies 
and  unclassified  professional  development  publications  for 
United  States  Naval  officer  warfare  specialty  qualf ication. 
In  this  section.  We  began  with  the  three  classic  threats; 
air,  surface,  and  sub-surface.  Literature  alerted  us  to  the 
necessity  to  include  la'nd  based  targets  as  a  potential 
"threat".  Later,  conversations  with  "experts",  especially 
"wargaming"   types,   proved  that  certain  aspects  of  weather, 
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general  jamming  environment  and  the  use  of  decoys  were  all 
matters  which  could  have  major  impacts  upon  threat  develop- 
ment. Through  an  involved  iterative  process  the  following 
seven  areas  of  "environment  and  Threats"  were  proposed  and 
accepted  as  inclusive. 

1.  SURFACE-  surface  ship  and  mine  threats 

2.  SUBSURFACE-  submarines,  swimmers  and  submerged  mines 

3.  AIR-  aircraft  or  missiles 

4.  LAND-  missile  sites  or  cities 

5.  JAMMING 

6.  DECOYS 

7.  WEATHER-    environment    including    temperature,   seas, 
visability 

At  this  point,  the  first  order  parameters  of  the  "Threat 
and  Environment"  had  been  identified.  Attention  was  then 
directed  toward  specification  of  the  independent  variables 
defining  each  of  these  seven  areas;  the  sub-elements,  if  you 
will.  The  process  described  for  the  determination  of  the 
threat  environment  was  repeated,  in  scale,  for  the  identifi- 
cation of  the  factors  constituting  each  of  them. 

The  investigative  method  used  in  the  detailed  development 
of  each  section  investigated  in  this  report  was: 
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1.  An  initial  estimate  of  the  elements  was  made. 

2.  A  literature  review  of  both  classified  and  un-classified 
sources  was  conducted  to  provide  a  first  refinement  of 
the  initial  list. 

3.  Private  enterprise  and  military  experts  were  consulted 
tofurther  refine  the  list. 

4.  The  initial  framework  of  the  section  was  established. 

5.  The  team  worked  with  the  thesis  advisor  and  contempories 
to  confirm  that  the  included  elements  had  proved  major 
impact  upon  the  next  higher  level 

definition  of  our  design.  This  work  also  ensured  that 
the  arrangement  of  the  variables  could  be  efficently 
implemented  within  the  DEX  framework. 


A  discussion  of  what  was,  and  perhaps  just  as 
importantly,  what  was  not,  included  in  this  example  section 
should  be  provided  to  demonstrate  the  process.  In  the  case 
of  overall  combat  situation  definition,  it  was  considered 
essential  to  include  the  elements  which  aided  the  ship,  as 
well  as  the  "threat".  Therefore,  this  section  would  have  to 
permit  the  presence  and  effect  of  friendly  or  aiding  ships, 
aircraft  or  any  other  such  elements  as  positive  contrib- 
utions to  the  operating  situation.  It  was  decided  to  assume 
that,  in  the  absence  of  information  to  the  contrary,  each 
side  (them  or  us)  had  any  capability  known  to  be  possessed 
by  either.  This  is  a  conservative  assumption  but  is  impor- 
tant for  several  reasons: 

development  of  either  side  as  a  complete  model,  automat- 
ically models  the  opposition. 
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most  operational  commanders  will  make  such  an  assumption 
in  the  employment  and  operation  of  their  ships. 


In  the  case  of  our  example  section  the  next  step  after 
identification  of  the  seven  major  areas  was  the  identifica- 
tion of  the  subelements  to  each  area.  In  the  case  of  "air 
threats",  the  author's  initial  estimate  of  the  appropriate 
subelements  to  "air  threats"  was: 


1 .  SPEED 

2.  ALTITUDE 

3.  NUMBER 

4.  SIZE 

5.  DECOYS 

From  several  visits  to  the  U.S.  Naval  War  College  and 
from  discussions  with  personnel  in  Washington,  D.C.  con- 
cerned with  weapons  system  development  and  intergrat ion, 
this  list  was  modified  as  follows  "speed"  became  two  speeds; 
inflight  speed  -  the  normal  "cruising"  speed  of  the  threat, 
and  "terminal"  or  final  speed  of  the  threat  as  it  made  a 
final  approach  to  the  target  (in  this  case  us!).  Although 
some  weapons  entire  flight  was  conducted  at  a  single  speed, 
it  is  much  more  common  for  the  majority  of  distance  from 
launch  to  target  to  be  conducted  at  the  relatively  low  speed 
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to  ensure  a  maximum  range.  Typically,  the  threat  will  then 
conduct  a  radical  altitude  change  manuver  such  as  a  "pop  up" 
from  a  low  altitude  approach  or  a  "dive"  from  a  high  alti- 
tude approach  to  effect  a  high  "terminal"  speed  attack  upon 
its  target. 

In  addressing  the  problem  of  multiple  targets,  ("number" 
in  the  original  list)  it  became  quickly  apparent  that  the 
threat  could  have  density  in  both  space  and  time.  Thus,  the 
type  of  "counter"  mounted  to  raids  of  different  sizes  and 
time/spatial  separation  was  quite  different.  These  threats 
must  be  allowed  to  be  accounted  for  separately  or  together. 

"Size"  quickly  proved  to  be  a  totally  inadequate 
description  of  the  "visibility"  of  the  threat  to  sensors  and 
was  quickly  replaced  by  "signatures".  Thus  the  list  had 
changed,  over  a  period  of  research  and  refinement  ^s 
follows; 

Air  Threat  Elements 

SPEED  In  flight  speed 

Terminal  speed 
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NUMBER  Target  density  (time) 

Target  density  (space) 

ALTITUDE  Engagement  envelope 

SIZE  Signatures 

DECOYS  Decoys 

In  the  work  on  the  subsurface  threats  there  were  like 
decisions  tr  be  made  which  will  be  discussed  to  show  some  of 
the  early  discisions  necessary  for  applicability  or  magni- 
tude considerations. 

At  the  stage  just  reached  in  the  listing  of  important 
"air  threat  elements",  the  applicable  "subsurface  threat 
elements"  were  assumed  as  follows: 

Subsurface  Threat  Elements 


SPEED 


RANGE 
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SIGNATURES  Radiated  noise 

Acoustic  cross  section 

DECOYS 

In  comparison  to  the  air  threat  development  at  the  same 
stage,  some  significant  differences  are  apparent  and  should 
be  explained.  There  is  no  subsurface  counterpart  to  either 
altitude  or  density.  In  the  case  of  depth  (subsurface  anal- 
ogy to  air  altitude)  detection  or  destruction  of  subsurface 
threats  was  assumed  to  not  be  affected,  to  a  first  rrder 
level,  by  the  depth  of  the  target.  This  is  a  good  example 
of  the  type  of  assumption  which  may  be  completely  reascable 
at  a  certain  technology  level  (point  in  time)  or  for  a  spe- 
cific type  of  analysis,  but  which  must  be  clearly  and 
completely  documented.  Such  documentation  is  mandatory  so 
that,  should  the  factors  justifying  or  allowing  such  a  sim- 
plification be  altered  for  any  reason,  the  model  can  be 
reconfigured  to  include  the  new  and  now  driving  consider- 
ation. In  our  example  the  omission  of  threat  density  for 
subsurface  threats  reflected  current  tactics  of  single  ship 
action,  vice  World  War  II  wolf  pack  type  operations.  Such  a 
methodology  even  today  may  be  highly  suspect  for  mine  field 
operations.  Speed  is  included  in  the  list  because  there  is 
a  wide  range  of  relative  target  speeds.   That  is  to  say  that 

31 


the  weapons   used   to  counter   such  threats  are,  typically 
working  on  the  extremes  of  their  capabilities. 

The   remaining  sections  of  the  threat/environments  devel- 
oped to  equal  degree  as  those  just  discussed  were  then: 

Surface  Threat  Elements 


SIZE 


RANGE 


SIGNATURES 

DECOYS 

Size  was  distinct  from  signature  to  account  for 
survivability  differences  between  vessels.  Most  existing 
algorithmns  for  survivability  are  based  on  overall  length  of 
the  vessel  in  question.  Note  that  speed  is  not  included  for 
surface  threats.  This  is  because  the  relative  speed  range 
of  all  possible  surface  threats  is  so  small  compared  to  the 
typical  weapons  used  to  counter  it. 

Land  Based  Threat  Element 
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Land  based  targets  are  included  as  a  significant  factor  in 
payload  requirements  because  the  destruction  of  them  is  a  current 
mission  of  some  U.S.  Navy  surface  vessels.   They  are,  in  effect, 
an  "anti-threat". 


SIZE 


RANGE  (TO) 


HARDENING  (the  degree  of  protection  provided  the  site) 


Jamming  Elements 

NOISE   (electromagnetic  energy  density) 

CHAFF   (physical  interference  with  electromagnetic  transmission  by 
use  of  metal  foil  ribbons  or  pieces) 


Weather  Elements 


VISIBILITY   (unaided  vision) 
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ELECTRICAL   Disturbance  (lightning,  sunspots,  etc) 

TEMPERATURE 

SEAS   (height,  period,  direction) 

As  might  be  expected,  the  next  stage  in  the  "top  down" 
development  process  was  to  "brainstorm"  the  elements  which 
directly  and  significantly  effected  each  of  the  threat  area 
elements.  For  example,  it  was  necessary  to  determine  what 
factors  "defined"  the  signatures  of  a  surface  threat.  A 
good  initial  approach  was  to  identify  such  signatures  by 
type  transmission  medium,  i.e.  air  or  water  borne  and  to 
further  break  down  these  mediums  by  the  types  of  energy 
transmitted  within  them: 

Air  Borne 

Electromagnetic  (energy  emitted  from  on  board  equipment) 

Visual  (reflectivity,  color,  roughness) 

Heat  (infra  red  energy  emitted) 

Noise  (acoustic,  air  borne;  used  in  detection  only) 
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Radiation  (sub-atomic  particle  air  borne) 

Water  Borne 

Radiated  Noise  (generated  in  the  operation  of  the  platform  itself) 

Sensor  Noise  (acoustic,  water  borne,  from  sensors) 

Radiation  (sub  atomic  particle,  water  borne) 

Wake  (physical  disturbance  to  normal  ocean  conditions) 

It  is  at  this  stage  that  we  are  truly  making  some 
progress  toward  our  goal  ;  the  identification  of  all  major 
independent  variables  defining  the  performance  of  a  surface 
combatant. 

This  is  an  excellent  place  to  point  out  one  of  the  more 
basic  errors  made  and  the  reasons  for  it.  One  of  the  air 
threat  element  identified  was  engagement  envelope.  This 
attempt  to  describe  the  threat  in  terms  of  the  magnitude  or 
means  of  the  counter  to  that  threat.  In  other  words  we  were 
artifically  defining  both  the  threat  and  some  of  the  parame- 
ters describing  our  counter  to  the  threat  by  defining  the 

35 


volume  of  space  around  out  ship  which  we  would  "defend". 
The  effect  was  to  be  describing  the  payload  required  in 
terms  of  desired  or  precieved  performance  as  an  input.  This 
is  not  what  the  model  was  developed  to  accomplish.  The  idea 
was  to  input  {or  define)  what  must  be  countered  by  the  com- 
bat systems  payload  and  have  the  model,  through  a  fully 
developed  and  broadly  considered  program  provide  appropriate 
means  to  actually  "defeat"  the  inputed  threat.  Therefore, 
this  approach  was  abandoned  and  the  orignal  premise  of  defi- 
nition by  need,  not  means  was  begun  for  the  air  defense 
problem.  The  final  list  can  be  f oundstart ing  on  page  lAI  of 
the  Appendix. 

Another  major  omission  of  the  threat/environment  section 
as  thus  far  developed  was  the  omission  of  the  difference 
between  weapon  and  weapon  platform  as  distinct  but  related 
factors.  It  was  not  sufficient  to  address,  for  instance, 
attacking  missiles  themselves.  It  is  entirely  possible  and, 
in  fact,  most  desirable  to  disrupt  the  air  borne  threat  by 
"defeating"  the  weapons  carrying  platform  prior  to  weapons 
release.  We  must,  therefore,  provide  within  our  model,  for 
the  total  of  all  elements  which  make  up  the  weapon,  the 
weapons  carrier  and  finally  the  two  together.  This  error  of 
omission  would  be  fundamental. 
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From  this  level  of  detail  on,  the  major  problem  was  of 
flow  -  cause  and  effect  of  each  stage  upon  the  other.  The 
subsection  of  the  example  threat  and  environment  menu  which 
was  fully  developed  was  the  "surface  threat".  A  detail 
listing  of  all  developed  menus  is  included  on  the  first  page 
of  the  appendix.  The  next  chapter  will  discuss  this  sub- 
section in  greater  detail. 
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CHAPTER  4 
DEVELOPMENT  OF  THE  OBJECTIVE  FUNCTION 

This  chapter  will  offer  the  methodology  for  the  develop- 
ment of  the  function  used  to  assess  the  design.  Each  menu 
string  in  this  model  was  designed  to  establish  a  hierarchy 
of  parameters.  That  is  within  a  given  string,  the  elements 
defining  a  parameter  are,  hopefully,  "downstream"  of  the 
things  they  are  defining.  However,  at  each  menu  level  there 
are  perhaps  as  many  as  8  to  10  different  parameters  of  equal 
status,  all  defining  the  next  higher  menu  item.  For 
example,  returning  to  our  example  menu  of  chapter  2,  we  see 
that  there  are  4  possible  weapons  choices  for  the  designer. 
How  would  the  designer  (model  user)  choose  how  many  of  each 
type  weapon  should  he  incorporate  within  his  vessel?  The 
ability  to  choose  the  proper  or  desired  combinations  of  such 
things  as  fire  power,  speed,  endurance,  survivability  or  any 
of  many  other  characteristics  is  essential.  It  must  be 
remembered  that,  in  general,  these  characteristics  compete 
for  vessel  resources  such  as  space,  weight  or  manpower  with- 
in a  design.  The  remainder  of  this  chapter  will  discuss  two 
possible  methods,  for  singular  or  combination  use,  for  this 
important  question,  spec  i  f  ic  ially';  given  that  the  model  (or 
any  model)  has  identified  the  pertinent  independent  vari- 
ables  in   naval   ship  design.   How  do  we  decide  how  much  of 
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each   is   best?   Or  in  other  words;  given  the  decision  vari- 
ables; what  is  the  objective  function? 


The  two  techniques  offered  will  be; 

A.  Utility  Theory 

B.  Artifical  Intelligence 

UTILITY  THEORY 

We  will  demonstrate  utility  theory  rather  than  define 
it.  Things  are  "worth"  more  or  less  to  an  individual  (or 
decision  making  group)  depending  upon  the  circumstances  at 
the  moment  of  evaluation.  Take  something  as  seemingly  well 
established  as  the  worth  of  a  dollar.  If  you  have  $50.00  in 
your  pocket,  a  dollar  does  not  necessarily  have  too  much 
value.  If,  however, you  only  need  $.60  to  ride  the  subway, 
but  have  no  money  at  all,  a  dollar  is  something  you  could 
really  appreciate  One  way  of  explaining  this  is  to  think 
of  the  utility  of  a  dollar  in  each  case.  Another  dollar,  if 
you  have  fifty,  is  not  too  useful  to  your  desire  to  go  home. 
In  the  latter  instance,  that  dollar  has  great  utility  if  you 
want  to  avoid  walking. 

Utility  theory  is  one  important  consequence  of  the  axioms 
of   rational   behavior.    A   person   who   accepts  the  axioms 
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.wishes  to  make  his  own  decision  processes  consistent  with 
them.  To  do  so,  he  must  always  select  decisions  so  as  to 
maximize  the  expected  utility  of  their  outcome.  The  fact 
that  it  is  the  expected  value  of  his  utility  which  he  must 
maximize  is  a  consequence  of  the  laws  of  logic  themselves. 

We  will  initially  limit  ourselves  to  the  case  where  a 
single  quantitative  attribute,  x,  is  considered  by  the  deci- 
sion maker  to  be  an  adequate  description  of  the  possible 
total  consequences  of  his  decision  problem.  Also,  for  sim- 
plicity, we  first  assume  that  the  decision  maker  prefers 
larger  values  of  x  to  smaller  values.  These  restrictions 
(single  numerical  attribute,  preference  for  the  larger  of 
two  values  of  that  attribute)  will  be  removed  later. 

Reference  Lotteries  and  Indifference  Probabilities 

Let  X  ,K^  ,..  be  the  particular  values  of  our  single 
quantitative  attribute,  x,  which  apply  to  the  consequences 
of  the  decision  problem.  Let  x"^  be  some  quantity  as  large 
or  larger  than  the  largest  of  the  x.'s  and  let  x^  be  a  quan- 
tity as  small  or  smaller  than  the  smallest  of  the  x.  's.  To 
determine  the  utility  of  each  x^  (and  therefore  of  the  con- 
sequence described  by  x  ),  we  first  establish  the  reference 
lottery  of  the  form  shown  in  Figure  4.1,  such  that  the  deci- 
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sion  maker  is  indifferent  between  ownership  of  this  lottery 
and  obtaining  the  consequence  of  value  x  .  This  requires 
the  measurement  of  p(x^),  called  the  "indifference  probabil- 
ity" for  a   consequence  of  value  x.. 

A  utility  U(Xj^)  can  then  be  assigned  to  each  consequence 
such  that 

U(x.)  =  kl  +  k2  p(x^) 
where   kl   is   any  constant  and  k2  is  any  positive  constant. 
For   instance,   if   we  set  kl  =  0  and  k2  =  1,  we  may  use  the 
indifference   probability    itself  as  the  measure  of  utility 
for  any  consequence.- 

Operationally,  the  procedure  is  not  so  useful,  because  it 
is  difficult  to  assess  the  p(x.  )'s.  A  decision  maker  finds 
it  hard  to  distinguish  between  probabilities  like  0.13  and 
0.17,  for  example,  since  one  does  not  have  a  intuitive  feel- 
ing for  many  probabilities  other  than  0.5.  In  the  next  sec- 
tion, we  demonstrate  a  method  for  obtaining  the  utility  of 
consequences  without  requiring  the  direct  assessment  of 
probabilities. 


A  technique  for  Utility  Assessment 
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Our  basic  concept  is  to  assess  the  utilities  of  a  few 
consequences  and  plot  these  on  a  graph  with  U(x)  as  the 
ordinate  and  x  as  the  abscissa.  We  may  arbitrarily  assign 
utilities  to  two  consequences  for  reference.   Let  us  set 

u(xl)  =  1 
and 
u(xO)  =  0 

where  xl  must  be  preferred  to  xO.  (This  normalization  is 
equivalent  to  specifying  the  values  of  kl  and  k2).  Then  we 
take  the  lottery  in  Figure  4.2  and  find  the  value  of  x,  call 
it  X.5,  for  which  the  decision  maker  is  indifferent  to  the 
lottery.  The  utility  assigned  to  x.5  must  equal  the 
expected  utility  of  the  lottery  so 

U(x.5)  =  0.5U(xl)  +  0.5  U(xO)  =  0.5  . 


This  gives  us  a  third  point  on  the  utility  graph  in  Figure 
4.3.  Our  technique  allows  us  to  obtain  the  utility  of  a 
third  consequence  x.5  relative  to  the  utilities  of  xl  and  xO 
which  were  set  to  establish  the  origin  and  unit  of  measure 
of  U(x).  In  obtaining  x.5,  we  were  able  to  keep  all  the 
probabilities  encountered  equal  to  0.5. 
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The   obvious   question   is   "how  does  one  get  x.5?"   This 

requires   an  interactive  procedure,  where  the  decision  maker 

must   state  his  preference  between  the  specified  lottery  and 

a   consequence.    For   instance,  we  would  choose  an  amount  x 

and  ask  whether  the  decision  maker  would  prefer  obtaining  x 

for   certain   or  particiating  in  the  lottery  shown  in  Figure 

4.4.   Regardless  of  which  is  preferred,  we  should  be  able  to 

identify  whether  x   should  be  increased  or  decreased  to  find 

a 

the  amount  x.5  such  that  the  decision  maker  is  indifferent 
between  it  and  the  lottery.  For  example,  it  might  be  obvi- 
ous that  x.5  >  X  .  Then  when  a  second  consequence  x,  is 
compared  to  the  lottery,  we  may  learn  x.5  >  x^  .  Such  infor- 
mation will  bound  the  true  value  of  x.5.  If  one  continues 
in  the  manner,  the  value  of  x.5  will  be  found. 

An  Example 

Let  us  illustrate  some  of  these  ideas  with  an  example. 
Suppose  we  wish  to  assess  your  utility  for  all  monetary  con- 
sequences between  zero  and  one  thousand  dollars.  You  can 
think  of  these  values  as  possible  changes  in  your  net 
assets.  Since  you  would  probably  agree  that  $1000  is  pre- 
ferred to  $0,  we  can  arbitrarily  set  the  origin  and  unit  of 
U(x),  where  x  is  a  particular  change  in  assets,  by  U(0)  =  0, 
U(IOOO)   =   10.   Our  next  step  is  to  determine  the  amount  of 
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assets  for  sure  which  you  feel  is  the  least  amount  for  which 
you  would  agree  to  sell  the  lottery  shown  in  Figure  4.5. 
That  is,  we  want  your  certainty  monetary  equivalent  for  this 
lottery.  Suppose  you  decide  it  is  $400.  Then  the  utility 
which  is  assigned  to  $400  must  equal  the  expected  utility  of 
the  lottery,  since  they  are  indifferent  and  expected  utility 
is  our  measure  of  preference.  Hence,  U(400)  =  0.5  U(IOOO)  + 
0.5  U(0)  =5.0.  We  continue  the  assessment  of  your  utility 
function.  Let  us  attempt  to  find  your  certainty  equivalent 
for  the  lottery  shown  in  Figure  4.6.  If  this  amount  is 
$180,  then  the  utility  assigned  to  $180  must  equal  the 
expected  utility  of  the  lottery.  So  U(180)  =  0.5  U(400)  + 
0.5  u(0)  =  2.5.  Next  we  assess  your  certainty  monetary 
equivalent  (CME)  for  the  lottery  shown  in  Figure  4.7.  Sup- 
pose your  response  is  $650.  We  have:  U(650)  =  0.5  U(IOOO) 
+  0.5  U(400)  =  7.5.  The  idea  should  be  clear  by  now.  Let 
us  plot  a  graph  of  U(x).  From  the  last  five  equations  we 
have  five  points  on  that  graph.  The  curve  in  Figure  4.8  is 
drawn  through  those  points  and  represents  your  utility  func- 
tion for  any  increase  in  net  assets  from  0  to  1000  dollars. 
From  the  curve,  we  can  see,  for  example,  that  the  utility  of 
$700  is  8.  That  is,  U{700)  =  8.  Similarly  U(500)  =  6.3  and 
U(200)  =  3.0. 
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'Some  Characteristics  of  Utility  Functions 

There  are  many  curves  which  we  could  have  drawn  through 
the  assessed  points  in  Figure  4.8.  For  instance,  we  could 
have  chosen  to  use  linear  segments  to  connect  adjacent 
points,  to  use  regression  analysis  to  find  the  best  fit 
quadratic  curve,  or  to  "wiggle"  any  curve  with  ups  and  downs 
through  the  given  points.  In  this  section,  the  problems  of 
choosing  appropriately  shaped  curves  is  addressed. 

Rather  than  just  evaluate  some  points  and  smooth  in  a 
curve,  it  seems  reasonable  to  fir'it  try  to  obtain  the  gener- 
al shape  of  the  utility  function.  This  structure  of  the 
utility  function  can  be  specified  by  ascertaining  whether  or 
not  the  decison  maker's  preferences  satisfy  certain 
criteria.  Each  of  these  criteria  puts  a  restriction  on  the 
form  of  the  utility  function.  A  useful  technique  is  to 
determine  the  general  shape  of  the  decision  maker's  utility 
function  by  obtaining  a  qualita'  ive  expression  of  his  pref- 
erences, and  then  to  choose  a  particular  utility  function 
satisfying  the  general  shape  requirements  which  is  also  con- 
sistent with  a  few  carefully  assessed  values  of  U(x). 


The  Art  of  Assessing  Utility  Functions 
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Assessing  utility  functions  is  perhaps  more  of  an  art 
than  it  is  a  science.  The  success  one  has  in  such  attempts 
is  closely  linked  with  the  analyst's  ability  to  communicate 
with  the  decision  maker  --  to  indicate  the  importance  of 
this  process,  to  enlist  his  support,  and  to  make  him  feel 
comfortable  with  the  assessment  procedure. 

For  discussion  purposes,  the  assessment  procedure  might 
be  divided  into  five  steps: 

1.  Preliminaries  to  actual  assessment. 

2.  Specifying  the  relevant  qualitative  characteristics. 

3.  Specifying  quantitative  restrictions 

4.  Choosing  a  utility  function 

5.  Checking  for  consistency. 

Preliminaries  to  Actual  Assessment 


Before  beinning  the  assessment  of  a  utility  function,  the 
concept  of  decision  analysis  should  be  discussed  with  the 
decision  maker.  Thus,  he  should  realize  the  purpose  in 
assessing  his  preferences  and  hopefully  be  sufficiently 
motivated  to  think  hard  about  his  feelings  for  the  various 
consequences.  It  should  be  made  clear  to  the  decision  maker 
that  the  preferences  of  interest  are  his  --  that  they  repre- 
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sent  his  subjective  feelings  --  and  that  there  are  no 
objectively  correct  preferences.  At  any  time  if  the  deci- 
sion maker  feels  uncomfortable  with  any  of  the  information 
he  has  offered  about  his  subjective  feelings,  it  is  perfect- 
ly all  right  —  in  fact,  necessary  for  the  correct  analysis 
for  him  to  change  his  mind.  This  is  one  of  the  purposes 
of  decision  analysis,  to  require  the  decision  maker  to 
reflect  on  his  preferences  and  hopefully  straighten  them  out 
in  his  own  mind. 


Specifying  the  Relevant  Qualitative  Characteristics 

The  qualitative  characteristics  we  are  interested  in  are 
monotonicity  and  attitudes  toward  risk.  To  ascertain' wheth- 
er a  monotonicity  condition  is  appropriate  is  quite  simple. 
One  asks  the  decision  maker  which  is  preferred  between  xl 
and  x2,  where  x2  >  xl.  Probably  you,  the  assessor,  would 
expect  a  certain  answer  to  the  question  based  on  your  own 
understanding  of  the  consequences.  If  x2  is  prefered,  you 
would  tend  to  think  preferences  are  monotonically  increasing 
in  attribute  x.  You  would  then  just  ask  whether  more  of  the 
attribute  is  always  preferred  to  less  of  it. 
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To   check  for  risk  properties,  you  might  divide  the  range 

of  the  attribute  as  illustrated  in  Figure  4.9.   We  would  ask 

the   decision  maker  whether  he  prefers  the  lottery  in  Figure 

4.10   or   its  expected  value  x   for  certain.   Note  that  this 

^  c 

lottery  covers  the  complete  range  of  the  attribute  for  the 
problem  at  hand.  If  x  is  preferred,  we  are  inclined  to 
think  the  decision  maker  is  risk  averse;  if  the  lottery  is 
preferred,  he  is  likely  risk  prone.  To  check  subranges,  we 
ask  for  preference  between  the  lottery  in  Figure  4.11  and 
its  expected  value,  x^^.  We  also  ask  the  decision' maker '  s 
preference  between  the  lottery  in  Figure  4.12  and  its 
expected  value,  x,  .  If  the  certain  amounts  are  preferred 
here,  as  well  as  with  the  first  lottery,  we  will  probably 
find  it  reasonable  to  assume  the  decision  maker  is  risk 
averse. 

If  sometimes  the  lottery  is  preferred  and  sometimes  the 
sure  consequence  is  preferred,  we  would  need  to  check  fur- 
ther to  see  whether  the  decision  maker  was  risk  prone  in 
some  region  of  x  and  risk  averse  in  another,  or  whether  he 
had  made  an  error  in  his  initial  responses. 

Specifying  Quantitative  Restrictions 
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To  specify  quantitative  restrictions,  we  perform  the 
assessment  of  some  points  on  the  decison  maker's  utility 
curve.  We  have  already  shown  how  to  do  this  by  assessing 
the  certainty  equivalents  of  a  few  lotteries.  There  are  a 
couple  of  pragmatic  points  to  keep  in  mind,  however.  First, 
the  consequences  used  in  the  questioning  must  be  meaningful 
to  the  decision  maker.  Secondly,  the  spread  of  consequences 
in  0,5  -  0.5  lotteries  must  be  large  enough  to  be  meaning- 
fully different.  That  is,  if  we  are  talking  about  a  utility 
function  for  $0  to  $1000,  it  is  not  very  meaningful  to  ask 
questions  about  the  certainty  equivalent  of  a  lottery  such 
as  the  one  shown  in  Figure  4.13  since  there  would  be  little 
perceived  difference  between  the  $500,  $520  and  the  certain- 
ty equivalent. 

Choosing  a  Utility  Function 

Once  the  qualitative  characteristics  have  been  specified, 
we  will  be  able  to  select  a  parametric  class  of  utility 
functions  which  satisfies  these  properties.  Let  us  desig- 
nate this  as  U(x/X)  where  X  represents  the  parameters.  We 
would  expect  at  most  three  parameters  to  allow  a  suitable 
representation  of  any  utility  function. 
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Then  if  x3  is  the  certainty  equivalent  for  the  lottery 
shown  in  Figure  4.14  we  know  U(x3/A)  =  0.5  U(xl/X)  =  0.5 
U(x2/  X  )  which  gives  us  one  equation  with  the  number  of 
unknowns  equal  to  the  number  of  parameters.  Using  such  cer- 
tainty equivalents,  we  obtain  the  same  number  of  equations 
as  parameters,  and  then  solve  the  set  for  the  parameters. 
This  will  provide  us  with  a  utility  function. 

Checking  for  Consistency 

There  are  many  different  consistency  checks  which  can  be 
used  to  detect  "errors"  in  the  decision  maker's  utility 
function.  By  an  error,  we  mean  the  utility  function  which 
we  have  assessed  for  him  does  not  adequately  represent  his 
true  preferences.  There  are  a  variety  of  ways  to  ascertain 
whether  certain  qualitative  characteristics,  such  as  risk 
aversion,  hold  for  a  particular  utility  function.  One  way 
can  be  used  for  a  check  on  the  results  of  another,  etc.  One 
generally  useful  check  involves  asking  the  decision  maker 
his  preference  between  any  lottery  and  any  consequence,  or 
between  two  lotteries.  In  both  cases,  the  expected  utility 
of  the  preferred  situation  as  calculated  from  his  utility 
function  must  be  greater  in  order  to  be  consistent.  Whenev- 
er  the   analyst  feels  uncomfortable  about  any  aspect  of  the 
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decision   maker's   utility   function,   it  would  be  useful  'to 
check  this  aspect  and  make  any  appropriate  adjustments. 
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MULTI -ATTRIBUTE  UTILITY 

Ships,  like  other  large  systems,  have  many  attributes  In 
general,  the  value  of  any  design  is  seen  to  be  some  U(xl, 
x2,...xn),  where  xl  is  a  single  attribute.  Our  next  goal 
will  be  to  assess  and  measure  U(x),  so  that  alternative 
design  with  different  x,  can  be  ranked  analytically.  This 
ranking  should  be  somehow  responsive  to  both  the  underlying 
attitudes  toward  varying  amounts  of  each  attribute  and  the 
relative  importance  of  different  attributes. 

When  many  attributes  are  considered  in  project 
evaluation,  it  is  commonly  assumed  that: 

U(x)  =    J2\   U.[x(i)]  =  J2^i\ 
i  i 

That  is,  utility  is  additive  and  linear. 

In  particular,  traditional  benefit-cost  analyses  simply 
assign  a  constant  dollar  value  (a  .  )  per  unit  of  each 
non-monetary  attribute,  and  then  add  up  the  resultant  bene- 
fits. Individual  preferences  are  summed  up  by  converting 
all  desires  into  a  "willingness  to  pay"  for  a  good  or  ser- 
vice, a  process  that  in  general  favors  the  wishes  of  most 
well-to-do  of  the  decision  makers.  The  consequences  of  this 
fact  are  s igni f icant  to  the  national  naval  budget  process. 
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The  most  interesting  of  cases  of  single-attribute  utili- 
ty functions  are  distinctly  non-linear,  so  the  simplifi- 
cation of  JJ^  (Xj_  )  to  a^^  (x^)  is  not  appropriate.  Given 
non-linear  utilities,  however,  it  is  then  permissible  to 
derive  U(x)  as 

U(x)  =  X)^i  ^^""i^ 
i 

Certain  sophisticated  benefit-cost  analyses,  for  example, 
use  nonlinear  demand  functions,  and  then  add  up  the  benefits 
derived  from  each  attribute. 

However,  consider  the  following  example: 

xl  =   endurance  range 
x2  =  maximum  speed 


Obviously,  the  importance  of  each  of  these  factors  will 
not  be  independent  of  the  other,  at  least  to  many  observers. 
For  example,  the  significance  of  maximum  speed  is  very  much 
damaged  by  endurance.  Therefore,  the  difference  between  the 
utility  of  low  speed  and  that  of  a  very  high  speed  is  great- 
er if  the  endurance  is  higher. 
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Note  that  Lh  >  La,  which  can  not  be  duplicated  by  an  addi- 
tive model,  in  which  U(0,X2),  ^2'^  contribution  to  utility, 
may  move  up  and  down  as  x^  changes, but.  A,  x  '  s  maximum  con- 
tribution to  utility,  must  be  constant,  regardless  of  the 
value  of  x^.  Note  that  U(xj^)  is  not  depicted  as  being  line- 
ar, either. 


Since  we  have  discarded  the  linear  and  additive  assump- 
tions for  multi-attribute  utility  functions,  you  may  wonder 
why  we  do  not  just  estimate  utility  directly,  as  we  did  for 
single-attribute  utilities:  choose  the  endpoints  (U=0,  U=l) 
use  a  50/50  lottery  to  determine  the  utility  midpoint 
(U=.5),  repeat  to  find  the  quartiles  (U=.25,  U=.75),  and 
draw  a  smooth  line  through  the  points.  In  three  questions, 
we  determine  five  points  on  the  utility  function,  and  with 
some  restrictions  to  ensure  the  curve  is  monotonic  to  assure 
a  smooth  function,  we  can  derive  a  reasonable  approximation 
of  the  shaoe  of  that  function. 
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However,'  when  we  attempt  to  extend  this  methodology  to 
multi-attt ibute  situations,  we  run  into  the  famed  Curse  of 
Dimensionality.  In  two  dimensions,  we  would  presum.able  want 
to  know  the  utility  of  at  least  five  points  on  each  axis  and 
their  intersections  in  the  planes:  Now  there  are  25  points, 
of  which  only  two  are  fixed  by  convention  {U=0,  U=l).  If 
the  determination  of  each  point  requires  one  question,  23 
questions  are  necessary  to  approximate  the  surface.  Three 
attributes  require  123  questions,  four  demand  623,  and  five 
necessitate  3123  questions.  Decent  results  would  be  unlike- 
ly beyond  2  dimensions:  even  the  most  cooperative  decision 
maker  will  be  hard  pressed  to  answer  more  than  a  hundred 
lottery  questions  thoughtfully.  Furthermore,  under  the  pro- 
posed assessment  technique,  the  maximum  possible  distance 
between  a  point  of  interest  in  the  attribute  space  and  the 
nearest  point  for  which  the  utility  has  been  assessed  is 
proportional  to  the  square  root  of  the  number  of  attributes: 
assessment  becomes  both  more  difficult  and  less  accurate  as 
dimensionality  increases. 

Theoretically  two  approaches  are  possible  to  solve  the 
multi-attribute  problem.  As  we  demonstrated  above,  the 
first  is  an  exhaustive  comparison  of  alternatives;  the  large 
number  of  assessments  means  this  method  has  little  or  no 
practical   merit.    The   second   approach  employs  behavioral 

59 


assumptions   to   approximate  the  exact  utility  function;  the 

decision   analyst  uses  these  behavioral  assumptions  together 

with    a    few    assessments  to   model    the   preferences 
analytically. 

This  second  approach  is  further  divided  into  two  schools 
of  thought.  The  Harvard-MIT  school  restricts  the  utility 
function  directly  through  "independence"  assumptions  about 
the  preference  between  subsets  of  the  attributes.  The 
Stanford  school  separates  the  utility  assessment  process 
into  two  stages:  first,  the  ordering  of  trade-offs  under 
certainty  among  the  attributes  and,  second,  the  assessment 
of  a  risk  preference  function  on  one  "numeraire",  or  rank 
order,  for  the  deterministic  ordering  derived  in  the  previ- 
ous stage.  The  basic  research  for  that  work  is  contained  in 
the  Ph.D  theses  of  D.  Boyd  and  Thomas  Green  at  Stanford. 
The  remainder  of  this  discussion  provides  an  overview  of  the 
Harvard-MIT  approach. 

The  Karvard-MIT  method  simplifies  the  problem  but  not  as 
severely  as  the  linear  additive  model  first  discussed.  The 
utility  function  ,  however,  is  still  decomposed: 

U(x)  =  f  U^(x^),  U2(X2),  .  -  .  U^(V 
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We  still  retain  the  individual  U^(x. ),  each  obtained  by  ask- 
ing 3  questions  per  rather  than  approximating  them  with  a 
linear  function.  Furthermore  we  will  find  some  more  sophis- 
ticated way  of  combining  the  U. (x.  )  than  simply  adding  them 
up.   Specifically  we  will  assume 

preferential  independence 
utility  independence 

Preferential  independence  is  an  ordinal  quality 
the  order  of  preferences  (involving  x  and  x  is  independ- 
ent of  other  attributes  (x  ,  .  .  .  x  ):  crudely,  the  choice 
between  two  attributes  is  the  same  regardless  of  the  level 
of  other  variables.  Specifically,  if  one  set  of  attribute 
levels  (x  ,  x_  )  is  preferred  to  another  set  x  ,  x^  )  when 
the  other  attributes  have  values  (x^,  x^ ,  .  .  .  x  ),  then  (x^ 

3    4'  n  '  '  1 

,  x^  )  is  still  preferred  to  x   ,  x   ),  even  though  the  oth- 

11  1 

er   attributes   take   on  different  values  (x   ,  x   ,  .  .  .  x 

) .   Symbolically: 


(x^,  x^)  I  (x   .  .X  )  >  (x^,  x^)  I  (x..  .  .xj 
(x^,  xp  I  (x'  .  .X')  >  (x^,  x^)  I  (x-  .  .X') 

12.  J  n       1         Z  3  n 


Here   is  an  example  which  illustrates  the  meaning  of  prefer- 
ence indeoendence : 
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CASE  A 
MAXIMUM  SPEED 


CASE  B 
CREW  COMFORT 


a   =  RESOURCES  NOT  USED  b  = 

a^  =  NLANEU\^RABILITY  IMPROVEMENT  b^  = 

2  2 

a   =  REACTION  TIME  IMPROVEMENT  ^^  ^ 

a .  =  TONS  OF  STEEL  AVAILABLE  b .  = 


NOISE  LEVEL 
VIBRATION  LEVEL 
LIGHTING  LEVEL 
CROWDING  INDEX 


IF  WE  KNOW 


a   =  10,000    a'  =  6,000 
> 


^2  = 


10% 


a'  =  20% 
2 


b   =  70db    b'  =  60db 

> 
b^  =  lOdb    b^  =  30db 


GIVEN  THAT 


a   =  15% 

a,  =  500,000 

4 


b^  =  1.0 

b,  =  53 
4 


THEN  GIVEN 


a   =  50% 
3 

a   =  100,000 
4 


b   = 


b   = 


75 
27 


or  any  other 
such  combination 


PREFERENCE  INDEPENDENCE  IMPLIES  THAT 
IT  STILL  HOLDS  THAT 


a   =  10,000    a'  =  6,000 


a^  =  10% 
2 


=  20% 


b   =  70db    b'  =  60db 
-'■         >   -^ 

b^  =  lOdb    b'  =  30db 
2  2 


The  ordered  pair  is  preferred 
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On   the   other   hand,   diet   problems  (among  others)  readily 
present  counter  examples  to  preference  independence. 

While  preferential  independence  does  not  hold  in  every 
case,  it  does  show  up  in  many  practical  situations.  Even 
where  it  is  not  true  of  one  statement  of  a  problem,  the 
problem  can  frequently  be  re-formulated  in  terms  of  vari- 
ables that  are  preferential  independent. 

The  second  and  much  tougher  assumption,  utility  independ- 
ence, specifies  that  the  shape  of  U(x)  as  x^    changes  (with  x^ 
(  i  7^  j  )   held  constant)  is  independent  of  the  level  of  the  x. 
With   respect   to   design  of  a  ship,  for  example,  if  the 
utility  curve  looks  like: 


U 


1.0-- 


P   P     P 

MIN  CRIT   0 


>^   PROFIT 

MAX 


then  utility  independence  allows  the  function  to  look  like 


U. 


P     P    P^ 

WIN  CRIT     0 

PROFIT 


MAX 


or 


P  P  P^ 

MIN        CRIT       0 
PROFIT 


MAX 
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if  safety  is  poor,  depending  on  U(Pmin,  Safety  Poor)  and 
U(Pmax,  Safety  Poor):  in  each  case,  half  of  the  utility 
change  takes  place  in  the  first  third  of  the  profit  range. 
But  it  can  not  look  like: 


or 


Our  U(Profit)  can  be  expressed  in  a  single  graph  as: 


U^^MAX'  ^AFE^ 


=  UtA 


U(P, 


MIN    AFE 


s   )  p 


MIN 


P        P 
CRIT     0 


MAX 


Once  U  and  U^  are  determined  (as  a  function  of  safety), 
the  utility  curve  for  profit  is  fully  defined.  If  we  know 
the  utility  of  some  amount  of  profit  P^  ,  given  safety  level 
1,  what  does  that  tell  us  about  U(Pq),  given  safety  level  2? 
Our  utility  independence  assumption  requires  that  U(PqS), 
always  be  some  fixed  proportion  of  the  distance  from  U^  to  U 
(S). 


TlV 
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Therefore , 

U(P,S)  -  U^(S) 

— — =  Constant 

U'^(S)  -  U^(S) 


so  letting   S  =  1   and  S  =  2, 


U(P  ,1)  -  Uvs.(l)  •  (U^(2)  -  U^(2) 
U(P^,2)  = : +  U^(2) 


or 


U^(l)  -  U^(l) 


U(Pq,2)  =  U^(2)  -  b^^2  •  U^(l)  +  ^1,2  *  ^^^0'^^ 


where 


_   (2)  -  "^'^' 


or 


U(P^,2,  =  a^_2  +b^_2  •  U(P^,1) 


where 

^1,2  =   "li<2)  -  fl,2  •   "if'l' 


X 


Now   a     and   b   ^  are  only  functions  of  safety  so. 


"'^0'-'  =  a^_,  +  b^_3  •  U(P^,2) 


Therefore, 


U(P,  2)  =3^2"^  ^1,2  U(P/1) 


65 


for  all  ?,  siuiply  a  linear  trans  forrr.ation  of  U(P,1). 

Equation  (A)  allows  us  to  prove  a  very  important  point: 
utility  ("shape")  independence  implies  that  preference 
between  lotteries  in  one  attribute  is  not  affected  by  the 
level  of  other  attributes. 


For  example,  given 


Profits   A,B,  or  C 
Safety   =1.0 


1-p 


we  know 

U(A,1)  =  p  •  U  (B,l)   +  (1-p)  U  (C,l) 

to  show  that 

U(A,2)  =  p-U(B,2)  +  (1-p)  -0(0,2) 

that  is,  the  indifference  between   A   and  the  lottery  is  main- 
tained when  safety  changes,  we  simply  note  (dropping  the 
subscripts) : 

U(A,2)  =  a  +  b  •  U(A,1)  =  a[p+  (1-p)]  +  b  [p  •  U  (B  ,  1)  +  (l-p)-U  (C,l)] 

=  p[a+b  •  U(B,l]+  (1-p)  [a  +  b  •  U(C,l] 

=  p  •  U(B,2)  +  (1-p)  •  U(C,  2) 
And  that's  why  it's  called  utility  independence! 
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We  have  discussed  preferential  independence  two  attri- 
butes with  respect  to  all  other  attributes,  and  utility 
independence  of  one  attribute  with  respect  to  all  others. 
The  independence  concepts  can  also  be  defined  in  terms  of 
other  numbers  of  attributes  --  but  such  properties  need  not 
be  demonstrated  in  order  for  the  following  technique  to  be 
justified. 
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Artificial  Intelligence 

The  second  technique  offered  will  be  called  broadly 
termed  artificial  intelligence.  Although  it  is  certainly 
true  that  a  computer  can  not  think,  it  is  foolish  to  over- 
look or  ignore  the  computer's  ability  to  recall  out  the 
actions,  good  and  poor,  taken  by  others.  In  simplest  terms 
decision  maker  acts,  not  only  on  his  own  opinions,  but  upon 
the  preceived  or  known  actions  of  thers  in  similar  circum- 
stances. The  field  of  "artificial  intelligence"  is  little 
more,  in  this  least  sophisticated  form,  than  pathed  actions 
made  by  the  computer  based  on  a  statistical  preference  of 
previous  human  decision  makers.  Although  this  research  will  * 
not  attempt  to  develop  the  scientific  basis  for  artificial 
intelligence  aided  decision  making,  it  will  stress  one  opin- 
ion. 

To  use  this  discipline  a  foundation  of  previous  decisions 
in  similar  circumstances  is  required.  Since  individual  lev- 
el decisions  are  being  made  in  existing  combat  simulation 
and  ship  synthesis  models,  the  retention  and  cataloging  of 
them  should  be  started. 

It  is  believed  that  both  utility  theory  and  artificial 
intelligence  might  prove  significant  aids  to  our  unresolved, 
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but  pivotal  problem.  The  ultimate  decision  of  which 
quanitates  and  in  what  proportions  should  be  included  in  a 
specific  design.  The  purpose  of  each  is  the  same.  Show  the 
decision  maker  how  to  include  his  preferences  within  a  deci- 
sion toward  a  consistently  defined  problem.  It  is  this  need 
for  a  common  definition  of  the  problem  which  must  be  solved. 
It  is  offered  that  we  have  multi  attribute  utility  theory  to 
address  the  number  of  elements  and,  perhaps,  artificial 
intelligence  to  assist  in  the  problem  of  multi  decision  mak- 
ers. The  two  techniques  may  prove  ultimately  complementary 
to  the  resolution  of  the  appropriate  ship  design  objective 
function. 
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CHAPTER  5 
THE  ASSET  SHIP  SYNTHESIS  MODEL 

A  method  must  be  found  to  translate  the  hardware  payload 

and  the  conceptual  platform  into  first,  comparable  terms  and 

second,   into  a   first  approximation  of  a  ship.   In  this 

project   the   following  characteristics  for  this  translation 
were  considered  desirable. 

1.  Executable  within  DEX  software. 

2.  State  of  the  art  model 

3.  Interactive 

4.  Able   to   take   full   advantage   of   this  models  the 
framework  of  the  model  we  have  proposed. 

The  most  efficient  method  of  achieving  the  second  of 
these  objectives  was  to  find  an  existing  ship  synthesis  mod- 
el which  was  developed  to  to  incorporate  many  if  not  all,  of 
the  aspects  we  identified  in  previous  chapters  as  essential. 
with  the  lim^itations  of  other  models  discussed  in  chapter  1. 
Independently  to  this  research,  the  project  team  was  intro- 
duced to  the  directors  research  team  at  the  David  Taylor 
Model  Basin  in  Carderock,  Md.  This  group  was  actively 
involved  in  the  development  of  a  ship  synthesis  model 
intended  to  provide  for  the  analysis  of  the  effect  of  tech- 
nological  changes   upon   a   ship  design  at  the  feasibility 
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stage  of  the  design  process.  The  "Carderock"  model  is 
excellent  for  the  purposes  of  our  effort.  This  is  because 
it  can  be  initiated  by  the  fewest  and  most  elementary  of 
descriptive  parameters.  In  addition  the  Carderock  model 
allows  for  development/modification  of  all  included  concepts 
in  extensive  depth.  Because  of  the  significant  efficiencies 
to  be  gained  by  using  an  existing  model  in  our  project,  and 
DEXs'  ability  to  accomodate  existing  analysis  code  with  min- 
imum modification  it  was  decided  to  develop  the  combat 
effectiveness  model  with  the  explicit  intention  of  using 
ASSET  as  the  vessel  synthesis  technique. 

The  Carderock  model  is  called  Advanced  Surface  Ship  Eval- 
uation Tool  (ASSET)  and  is  an  interactive  computer  program 
for  use  in  preliminary  evaluation  of  frigate,  destroyer,  and 
cruiser-type  ships.  It  will  ultimately  encompass  virtually 
all  major  technologies  that  are  relevant  to  the  design  of 
such  ships,  including  hullform  sizing,  hydrodynamics,  pro- 
pulsion, structures,  weights,  hydrostatics,  cost,  manning, 
space  requirements  and  survivability.  The  program  features 
design  synthesis  capability,  options,  including  interactive 
graphics  and  use  of  either  English  or  metric  units.  ASSET 
is  primarily  intended  as  an  interactive  tool  for  providing 
timely  resuts  to  engineering  queries. 
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ASSET  was  designed  to  avoid  the  pitfalls  typical  of  pro- 
grams of  similar  scope,  such  as  extreme  difficulty  of  use, 
poor  responsiveness  to  engineering  queries,  and  inadequate 
technical  depth  in  the  multidisplined  environment.  The 
ASSET  engineering  modules  for  ship  design  are  manipulated  by 
the  user  via  a  small  yet  powerful  set  of  commands.  ASSET 
was  designed  to  execute  interactively  via  a  teleterminal  to 
provide  desk-top  convenience  while  avoiding  delays  inherient 
in  batch  (card)  oriented  systems.  Finally,  the  ASSET  engi- 
neering tools  represent  most  of  the  major  technologies  that 
are  relevant  to  destroyer-type  ships.  ASSET  consequently 
allows  an  increase  in  engineering  productivity  during  the 
ship  design  cycle  by  allowing  the  user  to  apply  the  ASSET 
engineering  tools  in  an  easily-used,  responsive,  yet  techni- 
cally sophisticated  environment. 

Use  of  the  ASSET  engineering  system  closely  parallels  the 
classical  process  of  ship  design.  The  design  team  begins 
with  a  set  of  mission  requirements  that  the  proposed  ship  is 
to  accomplish.  Existing  design  data  and  computational  pro- 
cedures are  employed  in  an  iterative  sequence  to  derive  a 
ship  design,  as  exemplified  by  the  design  spiral.  ASSET'S 
value  is  in  the  automation  of  many  of  the  manual  processes 
performed  in  the  iterative  design  process.  Instead  of  manu- 
al search  through  lengthy  residuary  resistance  coefficients, 
ASSET  performs   the  search.   Instead  of  manual  construction 
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of  a  plot  of  hydrostatic  righting  are  versus  heel  angle, 
ASSET  draws  the  plot.  Instead  of  manual  storage  of  design 
data  in  notebooks,  ASSET  stores  the  data  on  computer  disk 
files,  from  where  it  may  be  easily  recalled  and  reviewed. 

Although  many  of  the  precesses  involved  in  the  design  of 
a  ship  are  automated  by  ASSET,  the  program  leaves  the  crit- 
ical engineering  decisions  to  the  designer.  ASSET  makes  no 
attempt  to  decide  whether  to  employ  waterjet  or  propeller 
propulsion,  whether  to  use  Newton-Radar  or  Wageningen-B 
propeller  curves,  or  whether  to  use  a  three  or  four  bladed 
propeller.  ASSET  makes  no  significant  design  decisions 
whatsoever.  The  program  employs  selected  algorithms  to  per- 
form selected  calculations.  The  designer  retains  essential 
control  of  the  program. 

PROGRAM  STRUCTURE 

PROGRAM  CONCEPTUAL  ORGANIZATION  The  system  is  composed 
of  five  principle  elements:  the  designer,  an  executive  pro- 
gram, a  series  of  computational  programs,  a  ship  design 
undergoing  generation  or  analysis  (called  "current  model"), 
and  a  data  bank. 

DESIGNER  The  designer  is  the  controlling  element  of  the 
ASSET   system.    Through  a   simply  command   language,   the 
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designer  directs  execution  of,  or  interaction  between,  the 
remaining  system  elements.  Although  capable  of  batch  (via 
cards)  execution,  the  ASSET  system  was  designed  as  an  inter- 
active tool  for  ship  engineering.  Consequently,  the  design- 
er typically  utilizes  ASSET  by  means  of  a  teleterminal  where 
commands  may  be  entered  and  results  of  those  commands  imme- 
diately reviewed.   Delays  are  thereby  minimized. 

EXECUTIVE  PROGRAM  The  executive  program  is  the  ASSET 
system  element  that  interprets  each  user  command  and  there- 
after performs  each  task  that  is  required  to  accomplish  the 
user  instructions.  The  executive  program  is  also  the  lone 
system  element  that  can  directly  interact  with  each  of  the 
other  system  elements.  Performance  of  any  given  user  com- 
mand generally  involves  the  remaining  three  system  elements. 

CURRENT  MODEL  The  current  model  element  of  the  ASSET 
system  is  the  temporal  collection  of  data  that  represents 
the  one  ship  design  under  generation  or  undergoing  analysis. 
All  program  computations  use  current  model  data  only.  The 
current  model  is  temporal  because  it  exists  only  during  exe- 
cution of  the  program.  To  become  permanent,  current  model 
data  must  be  transferred  to  a  permanent  storage  device. 

DATA  BANK  A  data  bank  has  been  incorporated  as  an  ele- 
ment  of   the   ASSET   system   for   the   purpose  of  permanent 
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retention  of  ship  data.  Entire  current  models  or  pieces  of 
a  current  model  may  be  stored  in  the  data  bank  under  a  name 
selectable  by  the  user.  During  an  ASSET  session,  ship  data 
may  be  transfered  from  the  data  bank  to  the  current  model  or 
from  the  current  model  to  the  data  bank. 

The  executive  program,  the  current  model,  and  the  data 
bank  can  also  be  employed  to  create  entirely  new  ships  in 
the  current  model  by  recall  from  the  data  bank  of  pieces  of 
data  from  different  ships.  For  example,  one  can  transfer 
ship  data  corresponding  to  the  propulsion  system  of  Ship  A 
from  the  data  bank  to  the  current  model  and  then  transfer 
hull  offset  for  Ship  B  from  the  data  bank  to  the  current 
model.  The  current  model  would  thereby  contain  a  vessel  of 
Ship  A  type  propulsion  system  but  Ship  B  type  hull. 

COMPUTATIONAL  PROGRAMS 

The  calculative  function  of  ASSET  list  performed  by  the 
element  that  consists  of  eleven  computational  programs. 
Each  program  represents  a  distinct  engineering  technology 
that  can  be  applied  to  the  design  and  analysis  of  ships. 
Through  a  simple  command  to  the  executive  program,  it  is 
given  to  the  computational  program.  Following  termination 
of  the  computational  program,  output  data,  selectable  by 
menu,   are  displayed  to  the  designer.   Certain  computational 
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programs  also  add  to,  or  modify,  the  current  model  -as  part 
of  the  ship  design-generation  process. 

COMPUTATIONAL  PROGRAM  TYPES  Three  types  of  computa- 
tional programs  within  ASSET:  initialization,  synthesis, 
and  analysis.  The  description  of  the  programs  within  each 
type  is  given  below. 

The  initialization  section  of  ASSET  consists  of  a  single 
program.  It  utilizes  simple  empirical  methods  to  calculate 
a  variety  of  ship  data.  As  its  name  implies,  a  primary 
function  of  the  initialization  program  is  to  provide  an  ini- 
tial starting  point  for  a  new  design  under  development  with 
ASSET.  A  secondary  use  of  the  initialization  program  is  in 
performance  of  high-level,  parametric  trade-off  studies. 

Six  synthesis-type  computational  programs  exist  within 
ASSET.  Each  program  is  concerned  with  a  single  technolog- 
ical area  of  the  ship  design.  In  contrast  to  the  initial- 
ization program,  each  synthesis  program  utilizes  rigorous 
analytical  techniques  in  computation  of  ship  data. 

The  third  type  of  computational  program  is  called  analy- 
sis, of  which  there  are  four.  Like  the  synthesis  programs, 
rigourous  analytical  techniques  are  employed.  The  principal 
difference   between  synthesis  programs  and  analysis  programs 
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is  that  synthesis  programs  modify  the  current  model.  Analy- 
sis programs  do  not  modify  the  current  model,  only  provide 
additional  information  about  it.  Also  unlike  analysis  pro- 
grams, synthesis  programs  can  be  employed  in  an  iterative 
loop  to  converge  on  a  ship  design.  The  process,  known  as 
design  synthesis,  is  simply  an  automated  traverse  of  a 
design  spiral  from  the  mission  requirements  to  the  converged 
upon  ship  design. 

COMPUTATIONAL  PROGRAM  FUNCTIONAL  DESCRIPTIONS 

The  function  performed  by  each  ASSET  computational  pro- 
gram is  described  in  the  following  section. 

INITIALIZATION 

This  program  is  normally  the  first  program  to  be  exer- 
cised after  assembling  a  new  ship  in  the  current  model. 
Data  is  thoroughly  checked  for  completeness  and  if  no  fatal 
errors  exist  within  the  data,  a  mini-design  synthesis  proc- 
ess is  initiated  that  contains  geometric,  hydrodynamic ,  pro- 
pulsion, performance,  and  weight  calculation  capability. 
Simple  empirical  methods  are  used  throughout.  The  calcu- 
lation sequence  used  by  this  program  is  as  follows: 
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1.  Input  data  are  checked. 

2.  Ship  weight  is  estimated, 

3.  Hull  is  resized,  if  requested. 

4.  Auxiliary  and  electrical  systems  are  sized. 

5.  Hullborne  ship  drag  force  is  calculated. 

6.  Hullborne  propulsion  system  is  sized. 

7.  Ship  range  or  fuel  weight  is  calculated 

8.  Ship  weight  is  recalculated. 

9.  If  the  ship  weight  calculated  in  step  8  does  not  equal 
the  weight  as  previously  calculated,  the  mini-synthesis 
cycle  is  repeated  from  step  3  until  weight  convergence 
occurs. 


HULL  GEOMETRY 

The  hull  geometry  program  defines  girder,  and  deck 
locations,  and  also  defines  superstructure  and  hull 
geometry.  Hull  offsets  in  the  current  model  are  scaled  and 
warped  to  define  a  new  fullform  that  meets  requested  phys- 
ical characteristics.  This  program  includes  portions  of  the 
Navy  program  "Hullform  Derived  from  Parent." 

This  module  calculates  scantling  data  for  the  ship  ele- 
ments defined  in  the  current  model.  The  calculations  are 
based  on  pressure  loading  data  which  are  either  calculated 
by  the  program  or   input  by  the  designer.   Scantlings  are 
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determined  at  three  longitudinal  locations  for  the  hull  bot- 
tom, hull  sides,  and  weather  deck.  Additional  scantling 
data  are  calculated  for  lower  decks,  bulkheads,  frames, 
girders,  beams,  and  stiffeners. 

HULLBORNE  HYDRODYNAMICS 

The  hullborne  hydrodynamics  program  calculates  ship  drag 
during  hullborne  operation.  Either  planing  hull  or  Taylor 
Standard  Series  drag-type  calculations  may  be  performed. 

HULLBORNE  PROPULSION 

The  module  performs  sizing  calculations  for  either  a 
waterjet  or  propeller  propulsion  system.  The 
water jet-propulsion  system  section  of  this  program  calcu- 
lates engine  power  requirements,  water-duct  losses,  pump 
size,  and  operating  data  based  on  given  drag,  duct,  and  pump 
type  data.  The  propeller  size,  and  propeller  operating  data 
based  on  given  drag,  gearbox,  and  propeller  characteristic 
data. 

FUEL/RANGE 

Range  performance  is  calculated  by  this  program  in  either 
of  two  ways.   The  weight  of  fuel  required  to  achieve  a  spec- 
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ified  hullborne  range  is  calculated  or  the  range  which  may 
be  achieved  by  a  given  ship  is  calculated.  The  calculation 
mode  is  specified  by  the  designer.  Fuel  requirements  for 
auxiliary  and  electric  plants  are  also  considered. 

WEIGHT 

The  weight  program  calculates  a  detailed  weight  breakdown 
for  the  ship.  The  weight  statement  follows  the  Navy  Ship 
Work  Breakdown  Structure,  SWBS.(see  OPNAV  Inst  9100.2b, 
1978) 

PERFORMANCE 

The  performance  program  calculates  the  performance  char- 
acteristics of  ship  designs  that  have  been  generated  via  the 
design  synthesis  process.  Whereas  design-synthesis  perform- 
ance calculations  assume  calm  water  and  a  clean  ship,  the 
performance  program  considers  fouling  effects  of  marine 
organisms,  degradation  of  machinery  with  time,  and  sea  state 
operation. 


COST 


The   cost  program  estimates  ship  costs  for  the  purpose  of 
design  tradeoffs  and  comparative  evaluation.   Both  unit  pro- 
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duction  costs  'and  life  cycle  costs  are  addressed.  Simple 
empirical  relationships  based  primarily  on  the  Navy  SWBS  are 
used  to  estimate  unit  costs.  Life  cycle  costs  are  estimated 
utilizing  a  variety  of  data. 

GEOMETRY  DISPLAY 

The  geometry  module  produces  plots  of  ship  geometry. 
Hull  lines,  bulkheads,  decks,  and  superstructure  can  quickly 
and  easily  be  assessed  for  correctness  by  the  designer. 

DESIGN  SYNTHESIS 

The  design  synthesis  process  is  another  step  employed  in 
the  manual  process  of  ship  design  that  has  been  incorporated 
into  ASSET.  After  establishment  of  mission  requirements, 
the  designer  typically  generates  an  initial  design  to  serve 
as  a  starting  point.  This  initial  design  may  be  a  previous- 
ly established  design  of  similar  function  or  an  entirely  new 
concept.  Unfortunately,  the  initial  design  is  seldom  satis- 
factory. Minor  or  gross  modifications  must  be  performed. 
For  example,  additional  cargo  volume  may  be  needed.  The 
designer  may  elect  to  expand  the  hullform  to  satisfy  this 
need.  But  expanding  the  hullform  changes  ship  resistance, 
which  impacts  required  propulsive  power,  which  may  demand  a 
new  power  plant,  which  may  change  the  amount  of  fuel  carried 

81 


to  achieve  a  desired  range.  The  modified  hull,  propulsion 
plant,  and  available  fuel  impact  the  total  weight  of  the 
ship.  The  initial  estimate  of  ship  displacement  for  which 
resistance  calculations  were  previously  performed  may 
require  revision,  and  new  resistance  calculations  may  need 
to  be  performed.  The  design  spiral  goes  on  and  on,  hopeful- 
ly toward  a  converged  design. 

The  key  to  operation  of  the  design  synthesis  process  is 
the  ability  of  each  synthesis  module  to  modify  the  current 
model.  Critical  ship  data  in  the  cuerrent  model  such  as 
hull  lines,  superstructure  characteristics,  hullborne  drag, 
hullborne  propulsion  data,  fuel/range  data,  and  ship  weights 
are  modified  during  the  synthesis  process,  each  by  the 
appropriate  computational  program.  Convergence  of  a  ship 
design  occurs  when  two  passes  through  the  synthesis  loop 
produce  virtually  indentical  designs. 

This  project  has  been  designed  to  implement  ASSET  through 
the  techniques  of  the  DEX.  Initial  investigation  with  the 
ASSET  development  team  has  confirmed  the  opinion  of  the  team 
that  initiation  of  ASSET  through  DEX  will  be  relatively 
straightforward.  It  is  expected  that  the  initialization 
section  of  ASSET  can  be  called  into  this  model,  through  DEX, 
in  as  few  as  4  menus  consisting  of  approximately  15-20 
design  parameters. 
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CHAPTER  6 
COMBAT  EFFECTIVENESS 

This  section  is  the  most  important  of  the  entire  project. 
The  development  of  this  section  focused  upon  the  following 
three  considerations. 

Completeness 

Accountability 

Applicability 

Completeness 

The  content  of  this  section  is  as  follows:  A.  the  situ- 
ation is  defined,  including;  the  composition  of  forces  on 
both  sides  (this  information  is  obtained  from  the  current  or 
a  redefined  situation  obtained  from  section  la  "Threats  and 
Environment"  B.  The  operation  or  employment  of  each  vessel 
is  specified.  In  this  sub  section,  the  opposing  forces  are 
further  defined  as  modeled  at  the  moment  at  which  an  esti- 
mate of  combat  effectiveness  is  desired.  The  sub  section 
will  prompt  the  user  to  specify  the  status  of  each  major 
parameter  of  the  opposing  forces.  It  is  intended  that  this 
potentially  laborious  task  be  eased  by  having  this  specifi- 
cation done  by  default.  That  is,  that  items  not 
high-lighted  by  the  user  are  assumed  to  be  operational  and 
in   operation   to  the  extent  of  availability  and  performance 
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previously  given.  C.  The  definition  of  combat  effectiveness 
is  assumed  to  be  an  unspecified  combination  of  the  amount  of 
"damage"  inflicted  upon  the  enemy  and  the  amount  of  surviv- 
ing capabilities  of  the  designed  vessel  after  the  action. 
Each  of  these  major  combat  effectiveness  parameter  paths  is 
developed  to  the  degree  required  by  the  other  two  consider- 
ations of  this  section;  accountability  and  applicability. 
Note  that  we  are,  again,  avoiding  answering  how  much  each  of 
these  paths  might  contribute  to  an  overall  definition  of 
"effectiveness".  Extensive  amount  of  discussion  with  opera- 
tional and  design  authorities  indicated  that  such  an 
evaluation  is  a  function  of 

How  the  totality  of  overall  conflict  is  perceived 

The  perceived  strength  of  enemy  in  general  area  (poten- 
tial immediate  opponets) 

Perceived  relative  strength  trends  of   the  opposing 
forces. 

Accountability 
In  various  areas  of  this  model,  extensive  menu  strings  are 
taken,  intact,  from  one  section  to  be  used  in  a  higher  level 
section.  As  such,  these  strings  must  be  correct  and  concise 
as  possible  for  all  sections  in  which  they  are  used.  They 
should  provide  the  difficult  balance  between  what  is  neces- 
sary to  sufficiently  specify  the  problem,  and  the  desire  to 
limit  the  total  number  of  possible  decision  points  to  sim- 
plify  the   execution   of   the  model.    The  method  used  to 
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accomplish  this  trade-off  was  "comparision  and  reduction" 
from  a  higher  (earlier)  section  to  the  section  under  devel- 
opment. For  example,  in  choosing  the  surviving  capabilities 
to  be  included  in  the  "Combat  Effectiveness"  section  (7), 
the  section  describing  the  payload  (3)  and  the  section  list- 
ing the  platform  characteristics  (5)  were  compared.  From 
the  gross  list  formed  by  the  total  of  the  two  sections,  a 
shorter  list  was  formed  by  eliminating  redundant  or  overlap- 
ping elements.  As  discussed  in  chapter  2,  this  reduction 
was  accomplished  by  weighing  the  opinions  of  several 
war-gar^ng  experts  (most  notably,  John  Corsey  of  the  U  S 
Naval  War  College)  and  personal  opinions  gained  by  the 
author  from  specific  literature  reviews  (see  the  bibliogra- 
phy section  on  "Professional  Publications"). 

As  might  be  concluded,  this  is  a  highly  subjective  proc- 
ess with  all  the  attendant  dangers  of  such  a  generally 
described  process.  Because  of  this,  the  validity  and  com- 
pleteness of  this  section  should  be  the  initial  area  con- 
firmed by  any  future  researcher  in  this  field.  Within  this 
section,  the  output  or  product  of  the  entire  project  is  the 
most  sensitive  to  changes  in  format  and  construction  of  the 
individually  included  menu  items.  To  aid  in  menu  account- 
ability, a  section  menu  to  section  menu  listing  for  the 
section  is  given  below. 
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COMBAT  EFFECTIVENESS  MENU  THREAT  MENU 

must  be  consistant  with 

"threats  neutralized"  "threat  type" 
(by  type) 

"threats  damaged"  "threat  types" 
(by  type/amount/area) 


COMBAT  EFFECTIVENESS  MENU  PAYLOAD  MENU 

must  be  consistant  with 

"self  defense  capabilities"  "payload;  self-defense" 

"force  defense  capabilities"  "payload;  force/area  defense" 

"offensive  threat  "payload;  offensive  threat 

neutralization  capabilities  neutralization  capabilities" 


COMBAT  EFFECTIVENESS  PLATFORM  CHARACTERISTICS 

must  be  consistant  with 

"flag  CCC  capabilities"  "flag  CCC  capabilities 
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Applicability 

This  term  is  used  to  indicate  the  constant  responsibility 
for  each  included  menu  item  to  be  necessary.  There  is  a 
conflict  with  this  desire  and  the  stated  "design  philosophy" 
precept  concerning  highest  level  development.  Because  of 
the  desire  to  give  precedence  to  the  design  philosophy, 
there  was  been  only  first  order  efforts  in  the  area  of 
applicability  in  the  model  as  a  whole.  In  the  Combat  Effec- 
tiveness section  the  availability  of  experts  and  excellent 
references,  allowed  some  significant  "winnowing"  of  the  sec- 
tion. In  general,  this  section  is  designed  around  the 
existing  gaming  algorithms  as  used  in  this  country.  Many 
elements  which  would  be  significant  to  the  naval  architect 
are  not  significant  to  the  combat  simulator  because  he  sim- 
ply has  no  way  to  account  for  them. 

Operation  of  the  Combat  Effectiveness  Section 

Once  the  user  has  defined  the  general  situation  from 
which  he  wishes  to  obtain  an  estimate  of  combat  effective- 
ness, he  is  ready  to  exercise  the  sections  computational 
areas.  Because  this  area  is  designed  to  be  the  most  innova- 
tive of  the  project,  we  will  describe  this  translation.  The 
sequence  would  proceed  as  follows: 
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DETECTION  RANGE  CALCULATION 


GRAPHIC  TECHNIQUE 

(MAXIMUM  SENSOR  RANGE  30  nm) 
TYPE  1 


On  m 


lOnm 


30  n  m 


DISTANCE  IN  nm 


DETECTION  RANGE  THRESHOLD  (67%)   =  10  nm 


FIGURE  CE-1 


1.  The  setting  of  the  conflict  is  established.  As  previ- 
ously discussed,  this  might  include,  weather,  other 
units  or  any  other  factor  which  could  affect  the  outcome 
of  the  engagement  as  modeled. 

2.  The  operating  status  of  the  units  is  defined.  Here  we 
specify  the  on/off  status  of  the  sensors,  weapons  or 
other  equipments  having  a  detectable  signature. 

3.  The  relative  position  of  the  conflicting  forces  is  set. 
There  are  several  range  possibilities,  with  attendant 
action  possibilities  including; 

Outside  of  sensor  range  (by  sensor  system) 

Inside   sensor   range,   outside   all  weapons  systems 
ranges 

Inside   sensor   range,  inside  weapon  systems  range  ( 
by  weapons  system) 

Inside  minimum  weapons  range  (by  weapons  system) 

4.  Action  is  joined  at  the  range  specified  in  step  3 


Once  either  unit  is  within  the  maximum  dectection  range 
of  an  operational  sensor,  the  detection  event  must  be 
resolved.  The  detection  event  can  be  looked  at  in  two  ways. 
The  probability  of  detection  at  a  given  range,  or  the  range 
at  a  given  probability  of  detection.  Since  we  need  the 
range  of  an  action  to  proceed  to  the  next  step  in  the  model 
we  will  use  the  range  at  which  the  target  is  assumed  to  be 
detected  by  the  sensor.  The  method  used  to  find  that  range 
could  take  many  forms.  The  most  accurate  might  use  histor- 
ical information  from  "similar"  encounters.  Another 
technique  would  be  to  use  the  design  specifications  of  the 
equipment.   The  third  method  might  be  algorithimic .   This  is 
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the  technique  we  will  use.  In  this  algorithim,  we  will 
assume  a  linear  "curve"  describing  the  distribution  of  the 
probability  of  detection  from  the  maximum  design  detection 
range  to  the  minimum.  See  figure  CE  1.  This  implies  that 
the  target  is  becoming  more  easily  detected  as  an  inverse, 
linear  function  of  range.  In  addition,  we  will  specify 
that,  not  withstanding  the  finite  probability  of  a  detection 
at  any  range  less  than  system  maximum,  the  target  will  be 
assumed  detected  only  when  the  probability  of  detection 
reaches  67%.  That  is,  in  67%  of  assumed  cases  the  target 
was  detected  prior  to  this  range.  In  the  example  on  the 
next  page,  dectection  will,  therefore,  always  occur  at  lOnm. 
This  assumption  is  not  as  artificial  as  it  might  appear,  as 
most  systems  and  systems  operators  do  not,  routinely,  per- 
form to  the  systems  "advertised"  specifications.  The  actual 
percentage  threshold  range  is  arbitrary,  of  course. 
Although  a  more  generous  threshold  detection  range  may  be 
specified,  it  is  not  important  to  the  technique.  An  example 
is  developed  in  figure  CE  1  in  graphic  form. 

Given  that  the  detection  has  occured,  the  next  opera- 
tional decision  would  be  to  join  or  decline  action.  If,  in 
the  model,  the  defined  situation,  (or  the  users  override, 
see  chapters  page  30)  specifies  action  the  model  proceeds  as 
follows. 

Weapons  Action 
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CIRCULAR  ERROR  OF  PROBABILITY  (C.E.P.) 
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GRAPHIC    TECHNIQUE 


lOnm 

WEAPONS  RANGE  IN  nm 
AT  10  nm  C.E.P.   =  500  yds 
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20  nm 


FIGURE  CE-2 


A  weapons  action  is  defined  as  the  determination  of  the 
number  of  expected  hits  by  a  given  weapon  upon  a  given  tar- 
get at  a  specified  range.  The  calculation  assumes  that  the 
system  is  operational  and  the  target  is  within  maximum  weap- 
ons range.  Of  the  many  possible  methods  of  such  a  determi- 
nation, this  model  will;  1.  Define  the  length  of  the 
engagement.  This  will  give  the  number  of  rounds  fired  based 
upon  the  systems  firing  rate  (note  that  firing  rates  are  not 
necessarily  sing.le  valued).  In  our  example,  1  minute  firing 
with  a  firing  rate  of  30  rounds  per  minute  gives  30  rounds 
fired,  2.  Calculate  the  weapons  "circular  error 
probability"  (CEP).  This  parameter  measures  the  expected 
dispersion  of  warhead  impact  points  as  a  function  of  range. 
In  simple  terms  it  describes  the  circle  within  which  50%  of 
the  rounds  fired  would  be  expected  to  land.  For  our 
example,  we  will  use  a  simplified  but  representative 
algothrim,  much  like  the  sensor  detection  format.  In  our 
example,  the  input  range  of  10  nm,  from  sensor  detection 
range  is  within  the  maximum  weapons  range  of  20  nm  and  the 
model  "opens  fire".  From  the  CEP  curve  ,  figure  CE  2,  the 
initial  CEP  is  500  yards.  Therefore  if  the  opponets  main- 
tain 10  nm  separation,  it  may  be  expected  that  50%  of  the  30 
rounds  fired,  or  15  rounds,  land  within  500  yards  of  the  aim 
point  or  target.   Again  we  simplify  by  assuming  perfect  aim, 

but  inclusion  of  an  aim  error  would  be  a  straightforward  but 
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forgone  matter.  The  next  problem  is  the  assessment  of  the 
effect  of  the  hits  (if  any)  upon  the  target;  the  damage 
assessment. 

Damage  Assessment 

There  are,  again  many  .methods  of  assessing  possible  dam- 
age inflicted  upon  a  given  target  by  a  specific  pattern  of 
rounds.  This  model  will  use  a  percentage  coverage  approach. 
In  this  approach,  the  percentage  of  the  CEP  covered  by  the 
target  (the  length  of  the  target  divided  by  the  CEP)  will  be" 
multiplied  by  the  number  of  rounds  landing  (randomly)  in  the 
CEP  (up  to  a  maximum  of  one).  This  gives  the  expected  num- 
ber of  rounds  landing  upon  the  target.  In  normal  practice, 
any  one  of  several  scientific  techniques  are  used  to  make 
this  number  an  integer.  In  the  case  of  the  model,  we  would 
use  a  random  number  generator  with  even  or  odds  last  digits 
determining  round  added  or  subtracted  from  the  integer, 
respectively.  In  our  example,  we  will  assume  a  target 
length  of  300  feet  (100  yards).  Our  target  "fills"  100/500 
or  0.20  of  the  weapons  dispersion  (CEP)  so  that  0.20  times 
15  rounds  or  3  rounds  are  assumed  to  impact  the  target. 
Although  the  amount  of  damage  inflicted  by  a  single  round  is 
not  independent  of  the  impact  point  along  the  ships  length, 
since  the  weapon  dispersion  is  random,  we  will  not  address 
any  difference   in   types   of  "hits".   Therefore  assuming  a 
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-A  vessel  forced  to  retire 


FIGURE  CE-3 


random  distribution  of  hits,  random  normal  is  acceptable, 
the  type  and  effect  of  the  damage  might  be  determined  by  the 
model  from  a  table  or  curve  such  as  figure  CE  3.  Again  the 
form  of  this  curve  is  critical  to  the  outcome  of  the  con- 
flict, but  not  important  to  the  development  or  execution  of 
the  model.  Damage  curves,  such  as  figure  CE  3,  exist  in 
several  places  where  combat  simulation  has  been  conducted 
for  decades. 

From  our  example  damage  assessment  curve  of  figure  CE  3, 
it  is  assessed  that  the  3  hits  inflicted  upon  our  target 
force  it  to  retire.  The  implication  is  that  the  opponet  is 
out  of  action  for  a  period  of  time,  but  may  return  to  action 
after  some  repairs.  This  type  assessment  (sunk,  retire, 
etc)  as  results  of  specific  damage  accumulations,  is  very 
subjective  but  absolutely  essential.  It  is  important 
because  it  affects  the  operation  of  the  opponet  and  thereby 
affect  the  actions  and  performance  of  both  sides.  This 
determination  of  elimination,  temporary  removal  or  degrada- 
tion of  a  unit  is  required  to  permit  the  model  to  conduct 
multi-unit  assessments. 

To  recap  our  example  Our  ship  (P)  detected  opponet  (K)  at 
10  nm  by  sensor  A.  We  engaged  ship  K  at  that  range  with 
weapons  system  B.  In  1  minute  of  firing,  we  inflicted  3 
hits,  forcing  our  opponet  to  retire. 
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This  is  interesting,  but  what  was-ship  K  doing  to  us  in 
the  meantime.  The  answer  is  ,  exactly  the  same  sorts  of 
things  we  were  doing  to  him.  Obviously,  certain  actions  by 
one  opponet  would  be  precluded  from  execution  by  the  outcome 
of  actions  by  the  other.  For  example,  if  we  suffered  enough 
damage  to  be  sunk  before  the  1  minute  of  firing  was  con- 
ducted, we  could  not  have  forced  our  opponet  to  retire. 
This  brings  up  the  problem  of  time  versus  event  modeling. 
In  the  simple  cases  we  will  describe  in  this  model  each  con- 
flict is  being  treated  as  a  separate  event.  A  more  accurate 
depiction  would  permit  the  proportional  sequencing  of  events 
to  form  a  multi-state  assessment.  For  the  present,  this 
model  must  address  each  change  to  the  combat  situation  as  a 
separate  entity. 

Measure  of  Effectiveness 

In  our  example,  ship  P  forces  ship  K  to  retire  (turn 
back)  with  50%  damage  to  its  systems.  In  turn,  ship  P  suf- 
fered uncalculated  damage  in  that  same  event.  To  state  how 
effective  P  was  against  K,  we  must  weigh  the  relative  value 
of  the  two  damage  states  of  the  opponets,  and  the  actions 
expected  to  result  from  that  damage.  Thus  our  measure  of 
effectiveness  is  the  desired  balance  between  the  two  differ- 
ent "combat  effectiveness"  menu  branches  of;  A  Surviving 
Capabilities  (starting  at  menu  page  )  and  B.  Threats 
neutralized   (starting  at  menu     page    ).   This  balance 
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must  be  established  by  the  designer  or  user  of  the  model. 
Most  likely,  a  comparision  of  the  different  results  of  a 
number  of  opponets  and  in  a  number  of  different  situations 
will  be  necessary.  Methods  of  obtaining  such  a  blending  of 
seemingly  conflicting  outputs  are  offered  in  chapter  4.  One 
additional  note;  even  this  extremely  simple  action  sequence 
shows  the  advantage  of  internally  consistant  computer  man- 
aged data  bases  over  more  conventional  approaches. 
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CHAPTER  7 
COMBAT  SIMULATION 

In  this  chapter  we  will  trace  an  example  of  the  combat 
simulation  section  module.  We  will  simplify  the  case  by  the 
following  assumptions: 

1.  Both  forces  fully  defined 

2.  Single  unit  interaction 

3.  Minimum  additional  external  factors  (weather,  jamming) 

4.  Fully  operational  units 

We  have  chosen,  as  our  opponents,  the  FFG-7  frigate 
class  of  the  U.S.  navy  as  it  might  be  expected  to  be  config- 
ured today,  and  the  Krivak  II  frigate  of  the  Soviet  navy. 
This  choice,  as  made  provides 

Approximate  equality  of 

size 

manning 

speed 

relative  positon  in  "order  of  battle";  that  is  the  rela- 
tive importance  of  the  ship  class  in  the  countrys'  total 
naval  force. 
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These  ships  are  designed  for  different  primary  warfare 
missions  {FFG-7  =  AAW,  Krivak  =  ASW) .  The  baseline  units 
and  situation  is  described  in  table  CS-1.  We  will  demon- 
strate the  modules  capabilities  by  explaining  its  ability  to 

1.  Model  the  revelent  parameters  of  the  specific  situation 

2.  Be   sensitive   to  changes  in  unit  configuration  opera- 
tional senario. 

Four  alternative  sets  of  combat  effectiveness  values  will 
be  attempted 

1.  Baseline/no  harpoon  missiles  on  FFG-7 

2.  Baseline/harpoon  on  FFG-7 

3.  Baseline/units  at  35  nm  initial  range 

4.  Baseline/Units  at  5  nm  initial  range 

The  model  would  retrieve  the  baseline  Krivak  and  FFG-7 
(Perry)  from  the  threat  (section  lA  menu  ),  and  (sec- 
tion 5  menu  ),  respectively.  See  table  CEl  for  high- 
lights. Thus  there,  will  be  four  cases:  Harpoon/35nm,  No 
harpoon/35nm,  Harpoon/5nm,  and  No  harpoon/5nm.  In  all  cases 
the  units  will  be  initially  unaware  of  the  adversaries  pres- 
ence. They  will,  therefore,  be  employing  an 
acoustic/electronic  emission  control  scheme  design  intended 
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to   optimize   the   respective   units  primary  warfare  mission 
area.   Table  CE-2  shows  these  conditions. 
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1st  CASE  (No  harpoon/35nm) 

In  the  initial  circumstance  we  will  assume,  due  to  the 
range  and  partial  emissions  control  posture,  of  both 
vessels,  that  neither  ship  "knows"  that  the  other  is  in  the 
immediate  area.  Thus,  our  situation  would  start  with  a 
detection  of  either  unit  by  the  other. 

1.   Sensor  performance   (detection). 

Examining   the  two  opponents  sensors  versus  the  appropri- 
ate signature  levels,  we  might  conclude  the  following: 

Air  detection  -  none 

Surface  (radar)  detection  -  none 

Electromagnetic  detection  -  potential  soviet  ECM  vs 
SPS-55  &  SPS-49:  potential  US  ECM  vs  DON-2  (less  than 
above) 

Acoustic  detection  -  potential  TACTAS  vs  soviet  VDS; 
potential  TACTAS  vs  soviet  propulsion 

DOMINANT  PROBABILITY 

1st  assumed  detection:  TACTAS  (convergence  zone)  on 
Krivak  II  at  28nm.  (see  chapter  for  assumed  sensor  per- 
formance algorithm:  use  max  range  of  90nm  (2nd  CZ))  Since 
no  weapons   are   assumed  to   have   range   to   exploit  this 
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detection,  situation  continues  until  range  closes  to  less 
than  15nm  at  which  time  FFG-7  launches  standard  missle  in 
active/ARM  {anti  radiation  missle)  mode  on  Helo  (lamps)  sol- 
ution -  note  that  FFG-7  class  would/should  attempt  to  main- 
tain maximum  standoff  if  possible.  Also  note  that  TACTAS  is 
not  assumed  to  provide  a  fire  control  solution.  The  possi- 
ble firing  doctrine  might  call  for  a  single  shot  with  ready 
second  round  fired  upon  damage  assessment  or  unacceptable 
first  weapons  telemetry  data.  In  this  situation  we  are 
going  to  assume  a  hit  based  upon  a  positive  random  probabil- 
ity less  than  1.0  and  an  out  of  action  status  to  the  Krivak 
with  40%  total  systems  degradation.  No  damage  or  missions 
interference  is  assessed  to  the  FFG-7. 

Considerations 

If  the  FFG-7  is  not  ARM  configured  and  if  LAMPS  is  not 
able/allowed  to  provide  fire  control  solution  or  weapons 
delivery  (not  discussed),  the  situation,  would  most  likely 
deteriorate  to  a  gun  fight.  This  assumed  that  the  sometimes 
accredited  anti-surface  capability  of  the  SSN-14  is  inaccu- 
rate. In  short,  the  margins  of  the  weapons  systems 
capabilities  totally  dominate  our  solution  and  must  be 
defined/specified/agreed  upon  to  validate  to  outcome  or 
specify  the  solution. 
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CASE  2   Harpoon/  35nm 

Same  as  Case  1  in  initial  aspects  up  to  the  weapons 
action  (each  side  has  the  same  sensors  as  case  1).  Note, 
however,  that  probablistic  models  of  detection  or  weapons 
performance  might  very  well  give  a  different  function  to  the 
beginning  of  the  problem).  If,  however,  the  situation  is 
considerated  constant,  the  following  trends  in  performance 
might  be  expected: 


LAMPS   still   needed   for   over  the  horizon  fire  control 
solution 

Harpoon   missile   deployable   at   opening   (from  initial 
detection  range)  target  up  to  55nm 

Lethality  of  harpoon  much  better  than  standard  missile 

This   model   would  more  often  assess  a  sunk  Krivak,  with  all 
that  event  might  imply  to  other  actions. 

Outcome  assessed 
Sunk  Krivak,  Undamaged  FFG-7 
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Considerations: 
The   possibility   of   damage   to  FFG-7  is  much  lower  in  this 
case   that   case   1.  Thus  it  is  a  much  better  situation  than 
Case   1  for  FFG-7  although  assumed  outcomes  might  be  consid- 
ered "equal". 


/■ 
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CASE  3   No  Harpoon/  5nm 

In  this  instance  it  is  assumed  that  the  two  units  are 
together  (that  formal  hostilities  have  not  started)  In  this 
situation  detection  is  assumed  and  valid  fire  control  sol- 
utions are  assumed  to  take  equal  amounts  of  time  for  both 
vessels.  Even  if  the  Krivak  does  not  begin/or  have  a  fire 
control  solution  before  the  FFG-7  the  only  appropriate  weap- 
ons on  both  ships  are  the  guns.  Given  the  number  /rate  of 
fire/size  of  shell  of  the  soviet  guns  over  the  U.S.  gun  the 
model  would  generate  3  hits  in  20  seconds  of  firing  (see 
example  weapons  system  performance,  Chapter  with  range  of 
5nm  and  8+nm)  on  the  FFG-7,  while  the  FFG-7  inflicted  only  1 
hit  upon  the  Krivak.  Using  damage  assessment  curves  we 
might  conclude  outcome:  FFG-7  out  of  action  -  70%  systems 
degradation.  Krivak  damaged  -  10-15%  systems  degradation,  no 
change  in  operations 

Considerations : 

If  LAMPS  not  airborne,  damage  potential  to  FFG-7  much 
higher.  there  is  a  very  high  potential  advantage  to  unit 
initiating  action  due  to  in  contact  status  of  both  units. 
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CASE  4   Harpoon/  5nm 

The  existance  of  harpoon  does  not  change  the  outcome  from 
CASE  III. 

Outcome:    Same  as  CASE  3   FFG-7  -  out  of  action;   Krivak 
-  continues  mission 
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Discussion 

The   operation   of  this  example  points  out  two  major  con- 
tributions of  this  project  to  the  naval  ship  design  process. 

It  provides  a  systematic  method  of  providing  consistant 
input  to  either  an  existing  war  gaming  model  or  a  model 
internal  to  this  project.  This  is  an  essential  element 
for  naval  ship  design  assessment.  DEX  provides  extreme 
flexibility  in  this  matter. 

This  project  permits  the  essential  communication  between 
the  various  design  levels.  In  deriving  our  objective 
function  (combat  effectiveness),  we  have  attempted  to 
use  the  parameters  important  to  each  significan  disci- 
pline involved  in  the  naval  ship  design  process.  This 
•  should  permit  the  participants  to  communicate,  in  common 
terms,  with  one  another.  In  short,  we  have  provide  a 
common  language  (the  model)  to  address  the  same  question 
(What  is  the  designs'  combat  effectiveness?). 
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SITUATION  BASELINE 


FFG-7 


SHIPS 


Krivak  II 


Dimensions 


L     135m 
B     13.7m 
H      30m 

41,000shp  gas  turbine 

30kts 


Propulsion 


Speed 


23.4m 
14.0m 
31.0m 

80,000shp  gas  turbine 

32  kts 


Helicoptors 
2  X  SH-2  (+)   (300kts/100mn) 


None 


Weapons 


Guns 


1.  1  X  77mm   (86rpm/16km  range) 

2.  1  30mm  close  in  weapon 


2  X  lOOmn   (  ?rpm/  ?rai 


Torpedos 
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2x3  tubes 


8  tubes 


Missiles 


MK13  standard   (AA/anti  surface) 

(10nm/55nm) 


SSN  -14  (215mn) 
SAN  4   (8mn) 


ASW  Weapons 


2  ASW  mortars 


Sonar 
SQS-56  (medium  frequency) 
TACTAS   (passive  array) 


Hull   (Medium/low  frequency) 
Variable  depth  sonar 
(Medium  frequency) 


Radar 


Electronics 


Airsearch 

SPS49 
Surface  Nav 

SPS  55 
Fire  control  (Gun) 


HEAD  NET  "C 


DON- 2 
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SPG-60   (Missile)^  Kitescreech    (Guns) 

EYE  Bowl     SSN-14 
POP  Group    SAN-4 

Other  Forces  in  Company    (from  threat/environment  section  lA) 

none  none 

Weather 

Winds-  10  kts  (from  north) 
Seas  -  3-4ft  (n) 
Visibility  -  13nm 
Precipitation  -  none 

Jamming  -  none 
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FFG-7 


EQUIPMENT  IN  OPERATION/SIGNATURES 

Krivak  II 


Primary  Mission 


Primary  Mission 


(AAW  Advance  Escort)  (ASW  Patrol) 

Propulsion   16kts  (patrol)     12kts  (>  cavitation  speed) 

SENSORS 

Sonars 


SQS-56-passive 
Tactas  -  deployed 


Hull  mounted  -  passive 
Variable  depth  -  active 


Active   Radars 


49-A  radiating/timeshare 
55  -  radiating 
Missile/gun  radar-  standby 


Head  net  C  -  standby 
Don-2  radiating 
Missile/gun  radar  -  standby 


ECM 


Auto  search  (passive) 


Search  passive 
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Communications  UHF/HF  - 

EMCON  (receive  only)  UHF/HF-EMCON  (Receive  only) 

(No  short  range  communication  techniques  (visual  horizon) 
due  to  single  ship  operations  by  both  sides.) 
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Chapter  8 
CONCLUSIONS 


This  project  offers  "sometime  original"  by  introducting 
a  high  level  objective  function;  combat  effectiveness;  at 
the  feasibility  level  of  the  ship  design  process.  It  fur- 
ther allows  all  participants  to  the  process  access  to  the 
assumptions  used  to  arrive  at  that  objective  function. 

As  discussed  in  chapter  1,  the  project  team  feels  that 
the  time  is  ripe  to  bring  combat  effectiveness  into  the  ship 
design  process.  Improvements  in  gaming  techniques  and  mod- 
eling have  improved  the  ease  of  including  combat  effective- 
ness within  the  design  process  at  the  preliminary  design 
stage.  While  it  is  a  fact  that  there  are  potential  improve- 
ments to  many  other  facets  of  the  process  to  be  made  by  this 
approach,  inclusion  of  the  considerations  raised  by  combat 
and  combat  operations  should  prevent  over  emphasis  or  out 
right  subopt imizat ion  upon  the  noncombat  considerations. 
The  attributes  and  potential  flexibility  of  DEX  (see  chapter 
2)  are  extremely  important.  The  complexity  of  the  ship 
design  process  demands  maximum"  integration  of  the  model  and 
the  user.  It  is  believed  that  specification  of  the  means  or 
equipment  too  early  in  the  process  should  be  avoided.  Such 
premature   definition   of  hardware  is  a  potential  disruption 
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to  the  total  process.  In  effect  it  is  something  done,  in 
many  cases,  too  early  and  it  is  the  remaining  portions  of 
the  design  which  suffer.  In  effect,  when  equipment  is  spec- 
ified to  satisfy  a  need  too  early  in  the  process,  it  may 
well  be  that  the  totality  of  its  impact  upon  other  later 
design  stages  may  be  missed.  This  model  is  believed  to  be  a 
major  attempt  to  include  all  significant  determinants  of 
naval  vessel  characteristics.  Eventually  all  design  proc- 
esses will,  conceivably,  be  addressed  by  such  a  systems 
approach.  The  author  feels  that  the  techniques  exist  to 
permit  this  effort  in  the  admittedly  complex  and  involved 
ship  design  process.  All  the  techniques  proposed  in  this 
model  ar-j  in  practice,  it  is  the  integration  of  them  under  a 
capable  software  system  which  is  a  major  contribution  of 
this  project. 


The  impact  of  weapons/sensor  performance  upon  ship 
design,  is  reflected  in  the  sensitivity  of  the  combat  effec- 
tiveness of  the  design  to  them.  The  combat  effectiveness 
figures  and  algothrims  from  chapter  7  are,  therefore,  a 
starting  point  for  the  ship  systems  designer.  If  they  rep- 
resent important,  even  vital  contributions  to  the 
effectiveness  of  a  ship  in  combat,  their  accuracy  is  crit- 
ical. The  authors  believe  that  the  naval  architect/marine 
enginee  '   must  become  actively  involved  in  the  determination 
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and  validation  of  any  such  techniques  used  to  drive  the 
design  process.  It  is  believed  that  such  algorithms  are 
extremely  sensitive  to  minor  variations  in  the  system  con- 
figurations. It  will  be  one  essential  task  of  the  naval 
architect/marine  engineer  of  the  future  to  provide  the  sci- 
entific interaction  between  such  causes  and  their  effects. 
It  is  this  person  who  might,  for  example,  best  model  a  con- 
ceptual weapons  effect  upon  an  assumed  hull  structure  to 
provide  a  curve  such  as  the  damage  assessment  curve  (like 
figure  CE  3) . 

The  framework  for  a  future  naval  ship  design  process  mod- 
el has  been  presented.  It  will  require  validation  and 
refinement.  The  next  step  in  this  project  will  be  the 
development  of  the  modules  to  support  the  framework. 
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APPENDIX 


This  appendix  consists,  in  order,  of  the  menu  all  devel- 
oped menu  strings  listed  below.  The  numbers  refer  to  the 
sections  defined  in  figure  1,  chapter  1. 


Threat/Environment   (la)   Surface  Threats   (pages  lal-i 
through  lal-22)' 

Non  Combat  Environment  (lb)  Command  Control  and  Communi- 
cation (pages  Ibl-i  through  lbl-14) 

Platform   Parameters   (3)  Signatures  (pages  3a-l  through 
3b-21) 

Platform  Parameters  (3)  Risk  Factors  (pages  3b-i  through 
3b-5) 

Combat  Effectiveness  (7)  All  (pages  7-i  through  7-7) 

Each   menu  section  consists  of  a  title  page,  a  mapping  of 
the  section  and  pages  of  1  to  4  specific  menus. 


1  1  c 


six  menus  have  been  left  blank  for  the  application  pro- 
grammer in  these  ares  to  insert  the  appropriate  information. 

For   readability  purposes,  the  eight  letter  abbreviations 
required  by  DEX  have  not  been  used  in  this  appendix. 
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